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TITLE OF THE INVENTION: 



Method for generating a simple kind of Artificial Consciousness in a computer, which has the 
capability to plan, generate automatically and execute machine-code for the solution of arbitrary 
programming-abandonments. (Automatic Programming) 

REFERECES: 

First announcement of this utility-patent "Verfahren zur Generierung einer einfachen Form 
kunstlichen BewuBtseins im Computer zur Befahigung selbsttatig planender Erstellung von 
Maschinencode-Programmen und deren Ausfuhrung zur Losung beliebiger gestellter Programmier- 
aufgaben" was the 2 nd November 1999 in Germany at the DPMA (deutsches Patent- und 
Markenamt = german Patent- and Trademark-Office). 

SPONSORSHIP STATEMENT: 
There was no sponsor for this invention and I'm a single independent inventor. 

BACKGROUND OF THE INVENTION: 

1 . Field of the Invention: 

The present invention relates to computer programming, and more particularly to automatic code 
generation. It relates also to learn-capable programs and artificial intelligence. 

2. Present State of the Art: 

Worldwide in the Field of Software-Development many employees are missing and the 
development tasks become larger and larger. 

Until now a given conceptual formulation is conceived and programmed by Software-developers. 
For relieving the programming there are "Wizards" which offer the possibility to generate basic 
parts of source-code after making interactive inputs on dialog-windows by a fixed given generator- 
scheme. 

Moreover company-specific scripts are written, which generate simple steadily repeated parts of 
source-code with variations on the same positions by reading out data out of ASCII-files. 



In every case the user first has to develop the generating script and then has to write the ASCII 
data for to read out, or - in the case of "Wizards" - has to make user defined inputs and after the 
generation of the frame-sourcecode has to develop the intrinsic functionality of the program. 
After it the source-code has to be compiled to become executable. But such programs are not 
adaptive. 

On the area of Al there are neuronal networks / fuzzy logic which can build expert-systems, which 
can absorb external attractions and have the capability to make adaptive decisions on these 
inputs, which means a kind of adaptive control system but they will not be able to plan and 
develop and execute machine-code an learn from its execution. 

In the decision 20 W (pat) 12/76 of the german patent court artificial consciousness was tried to 
generated in a patent application by a reflexive chain of video cameras and monitors - this 
procedure has nothing to do with that method. 

BRIEF SUMMARY OF THE INVENTION: 

It's an object of the invention to create computer based artificial consciousness. 

It is another object of the present invention to provide a method for giving a computer the 
capability to learn programming for itself. 

It's a further object of the invention to provide a system to make a computer plan and develop 
programs targeted to a pregiven programming-aim or to fulfill its basic needs. 

Therefore it first captures all processor exception-vectors (for a single process-system) or task 
exception-vectors (for a multitasking version) by own analysis-routines. 

Then the system generates numbers, puts them to a defined place in memory and then sets the 
instruction-pointer to that number for to execute it, like it would be a legal opcode. 

Before the number is executed the processor's registers are set to predefined initial conditions and 
one number is executed several times using different initial conditions. 

After every number-execution the system analyses, if an exception occurred or the number caused 
a jump or a write to memory and the concerned source- and destination-registers are determined 
and also the kind of instruction, which means its mnemonic. For every execution many theoretical 
source-registers and several possible commands are possible. Therefore one number is executed by 
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many predefined different initial conditions to determine the concerned source-register and 
operation most exactly. By the sum of the execution analysis data the command concerned 
mnemonic and the source- and destination-registers are determined. So the system itself learns to 
program in machine-code. 

Additional the absolute basic needs, which also have mono-cellars, are modelled: 

Pain means an attack to the program ( = overwrite) and hunger means loss of energy, which is 

modelled by a defined register (hunger = low values). 

The program has got two valuation-systems: one concerning the basic needs and one concerning 
the fulfillment of pregiven programming aim. 

After single numbers are executed two-number-combinations are executed and the effects of these 
combinations are determined. 

The valuation system determines if the combination is good or worse concerning the basic needs 
and the fulfillment of a pregiven programming-aim (it's possible to disable one of these two 
valuation-systems). 

The programming-aim concerning valuation-function is dynamic, which means the value-range of 
its valuation-results is valuated by a meta-valuation-system - and if the valuation-results are not 
very meaningful, which means, they're clustered near the min/max-boundaries or near zero or 
another value, the valuation-function is changed by the valuation-system itself and a revaluation 
occurs. If then the valuations results are worse than before, the modification is quashed and 
another valuation-function modification is tried until the revaluation results in unclustered 
valuation-results. 

When larger number-combinations are tried, the valuation-system omits to combine combinations 
which caused fatal exceptions, large jumps, extensive writing to memory, registers which should 
not be used, etc. or combinations which dislodge from the programming-aim. So not every 
additional number or combination in the total combination causes an exponential rise of needed 
calculation-time and disc-space. 

The larger the combination becomes the more restrictive is the programming-aim specific valuation- 
system concerning additional numbers=opcodes or combinations. Then additional combinations 
must appropriate the programming-aim. 

So the system learns to plan developing the desired routine. 

The solution-routines are retested by nearly all possible input-values and if it works fine it's 
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valuated by needed clock cycles and memory space and the most effective solution-routine then is 
disassembled and can be taken by developers to implement it into their projects as a subroutine. 



Fig. 1 shows the ER-diagram of the database-tables which contain the data of the AC-program. The 
in the middle shown CLT(i)-tables are created dynamically. The database is described in section 
1.3.2. 

Fig. 2-1 8 show the names, datatypes, value-range and meanings of the table's columns - some 
with additional examples, how they're filled. These tables are described in sections 1.3.2.1 to 
1.3.2.16. 

Fig. 19-21 show the value-assignments of the OxT and CxT-tables. Here the effects of the 
executions are analyzed, and the mnemonic and source+destination-registers are determined. 

Fig. 22 shows the value-assignments of the energyspecific tables ELT and EBT, which provide the 
analysis results of the actions concerning the modelled hunger. 

Fig. 23-24 show the flow-chart of the AC-program. 
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1 . SPECIFICATION 



1.1 Object of the invention: 

The objects of the invention are: 

a) to provide automatized software-development, 

b) to create computerbased artificial consciousness. 

With this method a simple form of artificial consciousness is generated using a computer, which 
acts aimless and arbitrarily in the beginning, but has the capability to learn from the effects of all 
its "behaviour", for to, when it knows the effects of every single behaviour or behaviour pattern 
( = combination), has the capability to join together its single actions targeting to a given aim or 
fulfilment of basic needs. 



1 .2 Derivation of technical feasibility and Definition of artificial Consciousness: 

1.2. 1 Philosophical basic liberations: 

(... are normally no ingredient of a patent specification, but indispensable for the explanation 
of the technical feasibility) 

If the prerequisite of consciousness of man would be a kind of soul which would be adventitious 
between cygot and birth, it world be possible to locate it by cogitation experiment: 
If you would cognitive cut the head and provide the carotids with oxygen and nutrient containing 
blood, the consciousness would surely be located in the head. 

If you would isolate the brain expect of the factitious supply, no conventionally information flow 
between the individual and the environment would be possible, but the "I am"-consciousness 
would surely be present. 

Over it it's theoretical now possible to cut the cerebral lappets for seeing, listening, smelling, 
tasting, feeling, equilibration, speech and the cerebellum and nothing more would be lost. 
If the front cerebral lappets would further be cut, you'd loose the possibility to compute with 
present knowledge and on the cut of several upper cerebral lappets you'd loose reminiscence, but 
the deepest basic "! am" would be remaining. 

=> If a kind of soul would exist, it would be located on the upper End of the phylum brain ##. 

Under consideration of the fluent evolution the primates would have a "soul" too; and other 
mammals too; and all other animals too; and the single-cellars too; and plants too; and 
consequently every cell of a multicellular life form too. 

=> A border of a "soul-adventitious" or an "I am "-consciousness between the life forms is 
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missing. 

=> Every cell of our body ought have its own soul (the evolutionary specialisation to neural-cells 

is, equivalent to the prenatal cell-fissions, fluent). 
=> A soul does not exist (it's not necessary to build consciousness). 
=> Consciousness originates during the evolution compulsively automatically. 
=> Inside the "dead" molecule of the DNA is the construction plan for generating consciousness. 
=> Consciousness originates by valuation of the own actions and its effects, with the reflection 

of the valuation-results on the adapting dynamic valuation-method. 
=> If no soul is necessary for generating consciousness, but only the complex "program" of DNA, 

then consciousness is also generatable by a complex reflexive computer-program. 

7.2.2 Basic Approach for the Generation of Artificial Consciousness: 

The doing of all, including the plainest individuals conduces the fruition of its basic needs. 
These basic needs are: 

a) no achiness : = no attack against the own system and 

b) no hunger : = no imminent loss of energy 

A complex program, in which these basic needs are modelled, and which can act freely and has 
the possibility to learn reflexively what its actions effectuate (like a child) and can reflect if its 
actions improves its situation in reference to its basic needs, builds up a valuation-system, an then 
plans with the actions from its learned knowledge and reflects again and so attains consciousness. 
When it later scans its own machine-code and then tests every of its opcodes and after it all 
opcode-combinations it discerns the effect of its opcode-combinations and their context and so 
attains self-consciousness and now has the possibility of self-reproduction and the aware 
improvement of its machine-code while reproduction and so starts its evolution (its so effective 
like man could improve its DNA while mitoses/meiosis implementing its experience of life). 



1 .3. Technical Doctrine how to generate Artificial Consciousness: 
1.3.0 Definition of the appropriated abbreviations: 

The programming works on every computer with any processor and on any operating-system. In 
the following /[/-indexed abbreviations correlate with Motorola processors, % means Intel 
processors, and vy-indexed denote PowerPC-RISC-Processors. 



- 9 - 

eq. = equivalent 

ASR^ = Adress Space Register 

BAT^ = BAT-Registers 

BC = BitCode: every Bit correlates with a Flag and combinations are allowed. 

CCR^ = Condition-Code-Register ( = Flags: Extension, Negative-, Zero-, Overflow-, Carry ) 

CISC = Complex-lnstructionSet Computer (p.e. lA^-and MCJ 

CPU = Central processing unit = Prozessor 

CR^ = Condition-Register (CR 0..7) 

CR^ = Control-Register 

CTR^ = Count-Register 

DABR^ = Data Adress Breakpoint Register 

DAR^ = Data Adress Register 

DB = DataBase 

DEC r = Decrement-Register 

DR^ = Debug-Register 

DSISR^ = DSI Status-Register shows the reason for DSI- and Alignment-Exceptions. 

EA = Effective Adress (memory access without using a register) 

EAR^ = External Access Register 

Rseg^ = Segment Register: CS; SS; DS, ES, FS, GS 



EFIags^ = 32-Bit-Register with the System-Flags: IDent-, VirtuallnterruptPending-, VirtuallnterruptFlag- 
AlignmentCheck-, Virtual8086Mode-, ResumeFlag-, NestedTask, InputOutputPrivilegeLevel, 
OverflowFlag, DirectionFlag, InterruptEnableFlag, TrapFlag, SignFlag, ZeroFlag, Auxiliary/Align- 
CarryFlag, ParityFlag, CarryFlag. 

EIP^ = Extended Instruction Pointer (4 PC^) 

ER = Entity Relationship (database-model) 

ESP^ = Extended StackPointer (^USP^) 

Exc. = Exception^. #DevideError, #DeBug, NMI IRQ, #BreakPoint, #OverFlow, #BoundRange 
exceeded, #UD (Invalid Opcode), #NM (device not available), #DoubleFault, invalid 
#TaskSwitch, Segment #NotPresent, #SS (StackFault), #GeneralProtection, 
#PageFault, #MF (FloatingPoint-Error), #AlignmentCheck, #MachineCheck. 

Exception^. Reset, BusError, AdressError, invalidOpCode, Div/O, CHK, TrapV, 
PrivilegeViolation, Trace, Interrupts, Traps. 

Exception^. System-Reset, Machine-Check, DSI, ISI, Ext.lnterrupt, Alignment, Program, 
Floating-Point unavailable. Decremented System Call, Trace, Floating-Point Assist. 



FFT = fast Fourier-Transformation 

FK = Foreign Key of a ER-Database-table 

FPR^ = Floating-Point Register 0.. 31 

FPSCR^= Floating-Point Status and Control Register 

GB = GigaBytes = 2 30 Bytes 
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GPR = General Purpose Registers: on Pentium^: EAX, EBX, ECX, EDX; ESI, EDI, EBP; ESP; EIP : 

on PowerPC^: GPR 0..31 ; and on Motorola^ the Data- and Adress-Registers. 
IA = Intel-Architecture 
IRQ = Interrupt-Request 
AC = Artificial Consciousness 
kB = kiloBytes = 2 10 Bytes 
Id = Logarithm dualis = log 2 

LR^ = Link-Register 
MB = MegaBytes = 2 20 Bytes 
MSR^ = Model Specific Register 
MSR^ = Machine State Register 
NMI = Non-Maskable-lnterrupt (highest Interrupt) 

NOP = NoOperartion-OpCode [=opcode without effect (except increment of IP^PCJ] 
OLB = OpCode Lower Byte = last byte in the opcode 

PC^ = Program-Counter ( = Pointer to the first byte in memory where the processor starts to 

fetch and execute an opcode) 
PK = Primary Key of a ER-database-table 
PVR^ = Processor Version Register 

RISC = Reduced-lnstructionSet Computer (p.e. PowerPC^) 

RTE^, = instruction: return from exception (loads SR and PC from Supervisor-Stack) 
SDR1^ = SDR1 -Register 
SPRG^ = SPRG 0..3 

SR A = StatusRegister (Flags^: Trace-, Supervisor-, + Interrupt-Maske: l 2 I-, l 0 , +CCR-Flags) 
SR^- = Segment Registers: CS, DS, SS, ES, FS, GS 
SRy, = Segment Registers 

SRR^ = Save/Restore-Register of Machine-Status 

SSP^ = Supervisor- StackPointer (A7 in Supervisor-Modus) 

TB^ = Time Base Facility: Time-Counter -» 2 64 -1 

TR^ = Table-Register: GDTR, IDTR, LDTR, TR 

USP^ = User- StackPointer (Aderessregister A7 in User-Mode, A7' in Supervisor-Mode) 
= = correlates 

$ = begin of a hexadecimal number 

C = result of bit-by-bit-AND over all following values [ = V 1 & V 2 &....& V n ] 

S = result of bit-by-bit-OR over all following values [ = V 1 j V 2 | .... | V n ] 

Y = number (sum) of the set Bits in the following value [ = (1 &V) + (2&V)/2 + (4&V)/4 + ...] 

V = for all of the following ... 

V" = for all other ... (except the following) 



7.3. 1 Procedure for generating artificial consciousness by comprehensible words: 



A computer system attains consciousness, if the active program, in which basic needs are 
modelled (see 1.3.5), has captured all exception-vectors and proceeds as follows: 
Generate a normal number, write it somewhere in the memory, put the program-counter = in- 
struction-pointer on it and execute it like it would be an opcode ( = machine-code-command) and 
analyze, what its execution caused and proceed so with all numbers^opcodes (until a maximum 
length) with many representative initial conditions (register-values and reference-contents of 
address-registers). 

Then use the saved opcodes which seldom caused an exception while using several initial 
conditions and evaluate if its execution increased or decreased its situation in due to its basic 
needs. 

Combine the opcodes, which didn't decrease the own situation, and evaluate the effects of the 
code-combination using several initial conditions and save the result of analysis. 
Plan combinations of those opcode-combinations which would increase the well being referable to 
the basic needs or could fulfill or approximate a given programming aim. 

1.3.2 Creating the Database of the AC-Knowledge: 

For to have the learned from actions persistent, and for to have convenient access to the large 
quantity of data, a relational database system with its tables and relations shown in 3.1 is created. 
For to increase access and to save hard disk capacity, equivalent primary keys in clusters and 
additional indexes for often used non-PK-rows. The ER diagram is shown in Fig. 1 . 
Processor-dependant and in dependence of the number of 32-Bit-OpCodes, the database can grow 
very large and so the access speed according to it slow. Therefore RISC-Processors are more 
applicatively for the AC-Procedure than CISC-Processors. But CISC-Processors, like in the IA, use 
not very much opcodes which are longer than 24 bit, wherefore it's possible to have with striped 
tables and additional index-hard-disks and a higher "obliviousness" on inefficient opcode- 
combinations, an acceptable performance too. 
The hard disc space problem in discussed in 1.5. 

1.3.2. 1 The Register-ldentifikation-Table [RIT - Fig. 2]: 

In the RIT the individual descriptors of the processor-registers and -vectors are typed first: Every 
Register gets a correlated identification-number, an assigned bit in the BitCode, a character 
describing the register-type, a consecutive number of the register-type and an optional description 
of the register. The register of the processor-flags (EFIagsySfy) gets the RegisterJD #0. The 
exception-vectors mostly are located in memory and are no internal processor-registers - to identify 
most of these important vectors they get a RegisterJD with negative sign, which correlates with 
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the exception-number. [If exception #0 is not RESET but a real exception, then all exception-vector 
RegisterJDs are displaced by 1: Register JD= -(ExceptionNr+ 1).] 
Fig. 2b shows a Motorola example of the RIT. 

1.3.2.2 The Operation-Identification-Table [OIT - Fig. 4]: 

Like in the RIT the registers, here in the OIT the most important operations get an identification 
number and a bit in a BitCode. 

The Operation Type pigeonholes the operation to an operation group, described in Fig. 4c. 

The Operation Mnemonic (needn't to be exact like using assembler) and the optional 

Operation Description describe the basic command. 

1.3.2.3 The initial-Condition-Table [ICT - Fig. 3]: 

Because of equal opcodes could cause different effects, in this table many representative initial 
conditions referring to all positive RegisterJDs are pregiven here. For every initial condition number 
(in the fig.3-example: -31. . + 30) for all positive RegisterJDs a sample of initial conditions is 
generated, p.e. using the Function in Fig. 3b. But only for all registers, which could contain 
mathematically used numbers, like data-registers, address-register-references and in the 
decremented reference of it [to include the command -(adr.reg.)], floating-point-registers and other 
special calculation-register (like p.e. MMX). 

With the content of the address-registers it's surely possible to calculate too, but their values 
mostly refer to values in memory, where the predefined reference-values of the are located. 
Therefore the initial conditions of the address-register-values should only gyrate circadian through 
the references. 

The StatusyEFIags^-Register higher bytes are always filled with the same initial conditions from 
SAC.actual ' Processor _Mode. The ConditionCodes in the lowest byte of Status^/EFIags^ have got 
variable initial conditions. With the Control-, Debug- and Machinestate-Registers and the other 
special registers is dealt carefully too - the always get the same default-values. 

1.3.2.4 The OpCode-Register-Table [ORT - Fig. 5J: 

For every form initial values by opcode-execution changed (destination-) register, in a loop over all 
possible source-registers it's ascertained which possible operation-types of the OIT could caused 
the value in the changed (destination-) register. 

For every appropriate source-destination-register-combination a table-entry is generated (unitary 
operators get the Register _ID source = -1) and for every matching operation-type between possible 
source and destination the OIT-belonging Operations BrtCode-bit is set [p.e. 
2 + 2 = 2*2 = 2"2 = 2«1 =2|4 = .,.=4 for one or two source registers 2 (the other could be a 
constant) and one destination-register 4]. 

The ORT-columns are described in fig. 5 and fig. 19 contains the value-assignment-algorithms. 
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1.3.2.5 The OpCode-Learn-Table [PL T - Fig. 6]: 

The OLT is a subsumption of the effects of the actual opcode on the various used initial 
conditions. In the first 6 columns informations of fatal effects of opcode-execution are collected. 
Then there's the difference between the instruction-pointer = program-counter -value after and 
before opcode-execution and after it the condition-codes which could have caused a jump 
[redundant to ICT .Register_Value{Register_ID = Q)]. 

Then in Register changed 'BitCode and Register source BitCode the Bits of all possible destination- 
and source-registers follow out of the belonging ORT-entries and after it in max Operation BitCode 
and min_Operation BitCode the bitwise ORed and ANDed BitCodes of the ORT '.Operations BitCode 
-Entries. 

The duration and time of opcode-execution are stored, and in aimvaluation analog 
VFT. Valuation _Function( ADT '.aim Valuation FunctionID ) it's appraised, how valuable the opcode- 
execution is in reference to reaching the programming-aim (value-assignment is shown in fig. 20). 

1.3.2.6 The OpCode-BaseTable [OBT - Fig. 77: 

The opcode-base-table shows the ascertained total effect of one opcode in reference to all initial 
conditions. Fig. 21 explains, how the evaluation (column-filling) happens, for so getting a "warrant 
of apprehension" of the opcode. 

The OBT contains the resume of all executions of the opcodes, which later is necessary for the 
aim-directed planning of code combinations. 

1.3.2.7 The Combinations-RegisterTables fCRTQ'J - Fig. 8]: 

The Combinations-RegisterTables are created dynamically, built analog the ORT, with the 
difference, that effects of opcode-combinations are analysed here. So the CBT(2) has got one 
more opcode in the primary key than the OBT=CBT(1), and CBT(3) has got three opcodes, etc. 

1.3.2.8 The Combinations-LearnTables [CL T(i) - Fig. 9]: 

Here the same is valid, like in the CRT(i). Analogous the OLT, one CLT(i)-row contains the effects 
of one opcode-combination in reference of the used initial conditions. 

Here first the column CLT(i). gradient aim valuation gains importance. While it was identical to 
aim valuation in CLT(1) = OLT, in CLT(i>2) it contains: CLT(i). aim valuation - CLT(i-1 ). aim valu- 
ation (see third line of fig. 20). 

1.3.2.9 The Combinations-Base-Tables [CBT(i) - Fig. 10]: 

Analogous the CBT(i) show the resume of the effects of all initial conditions in reference to one 
opcode-combination. The value-assignments are shown in fig. 21. CBT(n) (where n is the largest i) 
is the combination-plan-table - it's the place where the aim-solution-program originates. 
If ADT.aimJu//fil/ed_Ffag_Functfon(CPT-PK)='] (TRUE), the solution-program of the given aim is 
found and it'll be enrolled into the AST. 
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1.3.2.10 The Aim Solution Table [AST - Fig. 1 1J: 

For every given programming abandonment the found solution-programs, their lengths, execution- 
times and used registers and operations (-»bitcodes) are enrolled here. 

1.3.2.11 The Aim Description Table [APT - Fig. 121: 

The ADT assigns to every programming aim an identification-number, a short description, one 
bitcode-combination of the source- and one of the destination-registers which should be used (if 
possible) and one bitcode-combination of forbidden source- and one of forbidden destination- 
registers; further a string of former solution-programs which could be implemented, and a aim- 
solution-flagfunction which returns TRUE if the opcode-combination (program) solves the problem 
for the desired source- and destination-registers and finally an identifier which references to the 
valuation function in the VFT, that appraises the closeness to the complying programming-aim, 
which is among others dependant of this aim-solution-flagfunction. 

1.3.2. 12 The Function-Identification-Table [FIT - Fig. 13, 14]: 

In the FIT basic subfunctions are provided, which can be used for composing the energy valuation- 
function. 

It's introduced in two variations: 

a. ) for generating a dynamical valuation function in SQL, 

b. ) for generating a dynamical valuation function in machine-code. 

The alterable building of a valuation function is easier to accomplish in SQL, but the execution-time 
in machine-code is much faster and every new composed SQL-valuation-function has to be parsed 
again. 

In the future the valuation-function should only be composed in machine-code. This has the 
additional advantage that the AC-program could use some solved solution-functions again as 
subfunctions in the FIT for later use for composing the valuation-function. 

1.3.2.13 The Valuation-Function-Table [VFT - Fig. 15]: 

The VFT contains the dynamic valuation-system in reference to the own "well being" (energy- 
register) and to the closeness to the programming aim(s). 

The VFT .Valuation _Function( Type='E', SAC.EnergyValuationFunctionJD ) appraises 
energyspecific actions and the Valuation Functioni Type = 'A', SAC.AimValuationFunctionID ) the 
closeness to the programming aim(s). 

The V FT . Function ID Chain contains the concatenation of the FIT.FunctionJD's, that means the 
execution-chain of the subfunctions: Here causes NUM (see fig. 13b), that the following value is used as 
a number of byte-length, VALUE denotes that the following value is the column-number of the 
CPT = CLT(n), from which actual row the value is taken, EREG means the RegisterJD of the energy- 
register, S/DREG denotes the value out of ADT.all source/dest Registers BitCode and AIM F is the 
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result of the ADT.aimfulfilledFlagFunction. The unitary operations operate on the last result of the 
FunctionJD Chain and the binary operations on the last two results. 

On every accommodation, enhancement, or other amelioration of these valuation-functions the 
Valuation Function ID is incremented and a new entry with the modified Valuation Function is 
created and the efficiency of all valuation-functions are reappraised: 

VFT. Valuation _Function value = SAC. Energy '/Aim sell ' valuation _Func(...)\, for to have an 
efficiency-gradient for further improvements. 

The functionality of the dynamic valuation-system is described in 1 .3.7. 

1.3.2.14 The Status of the AC-Program [SAC - Fig. 16]: 

This table has no primary key and only one row. It contains status-informations of the AC-Program 
and two self-valuation-functions, which appraise the efficiency of the energy-valuation-function 
and of the valuation-function of the programming-aim-closeness (VFT) by evaluating the range of 
their valuation-results. 

These self-valuation-functions are, in opposite to the energy- and aim-closeness valuation- 
functions, not modifiable by the AC-program itself, but can be changed by the user. 

1.3.2.15 The Energy-Leam-Table [ELT - Fig. 17]: 

In the ELT data are stored about all energy relevant actions over the actual initial conditions, that 
means for all opcodes and code-combinations, which pertain the last data-register. 
The valuability of an energyspecific action is appraised according to ELT. Energy valuation = 
VFT .Valuation _Function( SAC . Energy _ Valuation Func ID ). 

1.3.2.16 The Energy-Base-Table [EBT - Fig. 18]: 

Like in the CBT(i) for programming-aim-closeness, in the EBT the effects of energy-changing 
opcode-combinations for all initial conditions are collected. 

1.3.3 Preparing the initial State of the System 

For to reset the system later into the initial state without booting, several pointers have to be 
latched. Afterwards all exception-vectors are intercepted by own routines, because of the initial 
trying to use arbitrary numbers as machine-opcodes, although many of these trying cause fatal 
exceptions, because they're illegal opcodes (not usable) or the opcode causes an exception on one 
of the initial conditions. Abnormal system end would be the consequence, if not ail exception- 
vectors would be captured. 

In the case that the AC-program should run preclusively, you'll have to 

a.) stop multitasking by disabling it by an operating-system routine or by setting the IRQ-mask of 
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the processor to NMI. 

b. )save all system-exception-vectors. 

c. ) set all system-exception-vectors to own analysing and handling routines. 

or if it should later run with other programs or perhaps with further AC-programs: 
a') increase own task-priority. 
b')save all task-exception-vectors. 

c')set the task-exception-vectors of the AC-program to own analysing and handling routines. 

d. )save the statu sregister^ (^EFIags^-) and the user-stackpointer. 

e. ) save the values of the other address-registers and of the data-registers. 

f. ) save the values of the segment-, control-, debug- and special-registers. 

g. )set exception-vectors, which load additional data to the supervisor-stack (p.e. on address- 

violation-exception several processors load additional information like access-address and 
opcode onto the supervisor-stack) to a this fact considering interceptor-routine. 

h. )set the privilege-vioiation-exception-vector to a special capturing routine. 

i. ) set one trap-vector to a routine, where the system should continue inside the supervisor-mode 

after this trap occurs. 

j.) execute this trap intentionally to change the CPU-mode from user-mode to supervisor-mode (the 

system now continues on the above set routine). 
k.)set the trace-exception-vector to an own trace-routine for later effect-analysis after number-as- 

opcode execution. 

I.) set the bits in the first word on the supervisor-stack so, that when the SR is loaded from SSP, 
the trace-Flag is set and the IRQ-mask is set to NMI (p.e. this is #$8700 on Motorola) because 
while the following base-opcode-learning no interrupt should be possible and after execution the 
effects should be analysed. 

See referring to this fig. 24a. 

1.3.4 Base-learning from execution of all single opcodes: 

1.3.4.1 OpCode generation and execution: 

a. ) Generate a 32-Bit-Number as an opcode, starting on #$0000.0000, later increase by 1. [if you 

already know the CPU instruction set, you can skip the opcodes which would overwrite 
memory (p.e. memory-move-commands).] 

b. )Set data- and address-registers, and the address-register destination-values and the values one 

DWord below on predefined test-values (initial conditions) and clear the condition-codes in 
EFIags^/CR^^ (or use several initial conditions too). 

c. ) Write the above generated opcode into the test-location in memory. Then fill the memory 

behind with zeros up to the maximum possible opcode-length, if zeros mean the mnemonic 
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"ORI #0, Reg.O" (or another effectless command) or fill with NOPs. 

This is necessary because on a long command the zeros are not meaningless [and then often 
less destroying (p.e. memory overwriting) than the NOP-corresponding opcode-number], and on 
a few processors a clearing of the trace-flag is possible in the while execution used user-mode 
too, which effects the execution of the following numbers as opcodes too [if now the zeros are 
not effectless, NOPs have to be used to prevent further effects (like memory- or program- 
selfoverwriting)]. 

After these zeros or NOPs the Trace-Bit-Cleared handler is following. 
d.)Set content of the supervisor-stack, which is loaded by return from supervisor-mode into 
important user-registers like EFIagsyStatus-Register^, \P^PC M , etc., so, that CCR will be cleared 
or set on initial conditions, IRQ mask will be set to NMI, the trace-bit will be set and the 
supervisor-bit[mask] will be cleared and the DWord behind is the location of the test-opcode. 
Now execute the return from supervisor-mode by the corresponding opcode-command (p.e. 
RTEJ: EFIagsyStatus-Register^ is now loaded by above described values and the test-opcode 
executes, because IP^/PC^ is loaded by its address. 

• If now a fatal exception occurs (except trace, p.e. privilege violation, etc.), the kind of 
exception is briefly shown graphically if desired, and it will be continued by generating and 
executing the next opcode. 

• If an initial condition dependant exception occurs (like address error, division by zero, ...), a 
relation between initial condition an exception is analysed [attention: on several exceptions, 
because of trace, an in many literature not documented combination of both exceptions 
(internal processor handling) can occur (p.e. using M68000 on Trap, Chk, Div/0 in 
combination with Trace).] 

• If no exception occurs (not even trace) the opcode-execution cleared the trace-bit (should 
never occur while executing single opcodes) and the handler behind the opcode is executed. 

• On Trace-Exception (normal case) a usable opcode was generated which execution-effects 
have to be analysed now. 

7.3.4.2 Analysis of opcode-repercussion and saving the analysis-result: 

a. ) After execution the EFIags^Status-Register^ and the data- and address-registers and the 

reference-values of the address-registers an the reference-values one DWord below an the user- 
stackpointer are saved for analysis. 

b. ) Verifying the own machine-code-checksum (of AC-Prg.) and the inactive copy in RAM (both 

without test-opcode placement): If checksum changed, the AC-program injured itself while 
executing the test-opcode (overwrote own parts of program). The corresponding corrupt-flag is 
set in the table. If the active version checksum changed jump into the inactive version, then 
compare both versions byte by byte and repair the corrupt version by replacing the bytes in the 
version with the changed checksum by the bytes from the version with the correct checksum. 

c. ) Check the supervisor-bitmask of the saved user-stackpointer on the supervisor-stack: If the 
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processor was in supervisor-mode before jumping into the exception-handler, although he was 
in user-mode during test-opcode execution, a combination of the normal trace-exception with a 
low-priority-exception occurred [p.e. on Motorola Div/O-, Trap- or Chk-Exception (not 
documented in the M68000er handbook)]. That means the processor first fetched the 
exception-vector of the just occurred low-priority-exception and loaded the statusregister and 
the program-counter onto the supervisor-stack and then he jumped, while being in this 
processor intern routine, before starting the corresponding handler of the exception-vector, into 
the trace-exception-routine, which caused a further loading of the program-counter and the 
status-register (where now the supervisor-bit(mask) is set) onto the supervisor-stack. 
By analysing the supervisor-bit(mask) on the supervisor-stack, it's now detectable, that before 
trace another low-priority-exception occurred; and by comparison of the second saved program- 
counter below on the supervisor-stack with the low-priority exception-vectors, now the primary 
exception before trace is detectable, which corresponding exception-number is stored. 

d. ) Comparison of the IP^/PC^ on the supervisor-stack with the address (placement) of the test- 

opcode-address: If the IPy/PC/j decreased, stayed unchanged, or increased by a value, which is 
larger than the longest possible opcode, the test-opcode was a jump-command. 
If the IPy/PC^ increased by 5 or more bytes and less than the longest possible opcode, it was a 
long opcode or a short forward jump. If no registers changed from initial conditions it was a 
short jump. 

This analysis-result is stored too. 

e. ) Comparison of the EFIags^/Status-Register^ and of all register-values and of the address-register 

destination-values and of the destination-values one max. address-length below [because of 
-(Adr.Reg.) ], with the original-values. 

In a bitmask now it's flagged which registers or its destination-values changed and it's 
analysed, which operations on which source- and destination-registers could have happened 
(heeding changes of EFiagsySFy and the result is stored in the ORT and OLT (see figs.5,19; 
6,20) and the OBT is actualised (fig. 7,21). 

f. ) If it was a jump-command, in the EFIags^/SR^ it's analysed if it was an conditional jump. 

1.3.5 Realisation of the basic needs: 

1.3.5.1 Realisation of artificial pain: 

Pain is caused by system-injuring. The basic pain in the biological evolution incidences already on 
monocellars and is the injuring of the DNA in the cell nucleus. If the DNA is damaged, the 
monocellar has to take time to repair its DNA using its resources. It does it by filling missing 
aminoacids in the defect half of the double helix by adding the complement aminoacids to the 
undamaged haif. 

The AC program is loaded twice into RAM. If the AC program (or another one) executes a 
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command which overwrites a part of the active or inactive AC program, which means an injuring 
of the active or inactive code (DNA), it has the ability to recognise the damage by comparing the 
checksum, and has now to take time to repair the damaged code by comparing damaged and 
undamaged code to have information about the damage-location (valuable information for test- 
opcode analysis) and then copying the code from the undamaged version into the injured version 
to heal itself. If the active code was the injured one (had the corrupt checksum), it first has to 
jump into the inactive duplicate to prevent errors on self-healing, because the healing-routine itself 
could be damaged. 

1.3.5.2 Realisation of artificial hunger: 

Hunger means imminent loss of energy. Energy is engendered in the cells by transforming 
adenosintriphosphat to adenosindiphosphat. The energy for building up adenosintriphosphat from 
adenosindiphosphat is gained by combustion of glucose. Missing energy (ATP) makes metabolism 
and with it every action, reaction on pain, or self healing on injury, impossible. 
The "energy quantity" of the AC-program is modelable by the height of a value in a data register. 
Now it would be possible to realise hunger by decreasing the electric current to the processor by 
external reading of this data register and increasing an ohm-resistance inverse proportional to the 
register value. 

A less authentical hardware-unbound solution is possible too: 

Less energy is harmful for learn-process. Frugal values in the energyspecific data-register cause 
lower functionality on learning from opcode-executions. On less values no learning from opcode- 
execution is possible. And lowest values cause loss of the saved knowledge from earlier opcode- 
executions. If the value is zero, additional pain, which means own code injury, occurs. 
On hunger the AC-program consequently has to find and execute opcodes, which increase the 
value of the energyspecific data-register. 

Decreasing energy, which means the origin of hunger, is simulated by decreasing the 
energyspecific data-register by 1 after every action (=opcode-execution) [p.e. by the AC-program 
itself]. 

1.3.6 Planning on the criterions of the valuation-system: 

If the system tested all possible opcodes and analysed the effects of the suitable commands, it 
has now the possibility to learn planning aimed to comply its basic needs or its programming-aims: 
Therefore it combines the opcodes, executes them using all initial conditions and analyses, what 
effected the code-combination on every single initial condition. 

Because mostly longer opcode-combinations are necessary to fulfill the programming-aim, it plans 
the code combination by using only codes which caused no injury (own damage) or better no RAM 
access at all and caused no fatal exceptions (divide-error or overflow-exception are allowed) and 
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used no forbidden registers or opcodes (ADT .unused ' Registers _BitCode\ ADT .unused ' Operations- 
BitCode). OpCodes which use the desired destination and source-registers are preferred 
(ADT .all 'source/dest Registers BitCode) . 

ADT .aim fulfill ' valuation mode appoints, if the valuation-function is existent in SQL or directly in 
machine-code. For the beginning user the slower SQL-version is more convenient and the specialist 
would prefer to use an assemb\er-aim_fu/fi//ed_Ffag_Function (ADT) which is transformed into 
machine-code, because it's much faster on complex valuation-functions than SQL. 

1.3. 7 The dynamic-reflexive valuation-system: 

1.3.7.1 Valuation of the programming-aim closeness: 

The ADT .aim f ullfilled Flag Function( AimID ), returns TRUE, if the programming-aim is obtained 
and the VFT '.Valuation _Function( Type = 'A', ADT '.aim fullfilled ' Flag _Function , VFT .Function ID- 
Chain ), supplies a signed-byte value, which means the closeness of the actual CLT(n)-opcode- 
combination on the used initial conditions to the aim-solution. The result is stored into 
CLT(n) .aim valuation and builds up in comparison with the last CLT(n-1). aim valuation the gradient 
CLT(n) .gradient aim valuation. 

Because of the solution program has to work for all initial conditions, the maximum- and the 
average valuability of the opcode-combination, both as average over all initial conditions, is stored 
in CBT (n).max_aim valuation and CBT (n).avg aim valuation ; and the gradients to the 
corresponding values of the last CBT(n-1) build up CBT (n). max grad ' aim valuation and 
C BT ( n ) . a vg grad aim _ valua tion . 

If the boundary-value of -128 or +127 was the valuation-result, the VFT .boundary _value_counter 
is incremented, and analog low value counter is incremented, if a valuation-result between -16 
and + 1 5 occurred. 

Using these statistical data, and on an analysis of all CLT(i). aim ^valuation -values, p.e. if you count 
the number of values in a small value-range running from min-possible-result to max-possible-result 
(-127 to +128) in dependence of the width of the value-range-window, the 
SAC. Aim Self Valuation Func appraises after every programming-aim attainment the valuation- 
results of the VFT .Valuation Function and with it its efficiency. 

If the most valuation-results of the VET .Valuation Function p.e. were near the boundary-values 

(min./max.), the valuation-function was too steep and has to be flattened, which means inside the 

VFT .Function ID Chain have to be more elements with negative FIT .Function Flatten. The 

opposite is valid, if the most valuation-results caused a high VFT .low value counter. 

So after every solution of a programming-aim a self-valuation of the valuation-function occurs and 

a further step in the self-programming of the valuation-function. New elements are added to the 

valuation-function and sometimes elements are omitted and the steepness is adapted. 

Then the valuation is done again and it's revised if the new valuation-function would have supplied 
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a better range of valuation-results. 

If the new range of valuation-results was worse than the one before (valued by 
SAC.Aim Self _Valuation Function) then the modification of the valuation-function is quashed and 
another modification is tried. If the changing of the valuation-function ameliorated the range of 
valuation-results and the self-valuation-function returns a positive value, then it's continued with 
the next programming-task - otherwise a further amelioration of the valuation-function has to be 
done until self-valuation returns a positive value. 

1.3.7.2 The dynamic energy-valuation-function: 

The dynamic energyspecific valuation-system runs as follows: 

0.) Because of the results of the energyspecific valuation-system are constricted to the range of 

signedbyte the valuation-function is embedded into a frame: 

valuation-result := MIN[ MAX( valuation-function, -128), +127) ] 
1 JThe energy-valuation-function of 0-th order is "how saturated am I after the action ?": 

valuation-function(O) := MIN[ MAX( Energy after , -128), +127) ] 

2. ) The valuation-function of 1st order is "how much more saturated am I after the action than 

before ?": 

valuation-functiond ) : = MIN[ MAX( Energyafter - Energy before, -1 28), + 1 27 ] 

3. ) Because of the energy-register is of the type unsigned integer (DWord), the boundaries of the 

valuation would too often the result. Therefore a kind of logarithm or ... 
valuation-function{2) := MIN[ MAX[ SQRT( Energy after - Energy before ), -128], +127] 

4. ) Now negative energy-gradients would cause wrong signs, therefore 3rd square or ... 

valuation-functionO) := MIN[ MAX[ SGN( EnergyGrad )*SQRT( EnergyGrad), -128], +127], 

where EnergyGrad = Energy after - Energy before 
Possibly the function y 2 -SGN( EnergyGrad )-SQRT( SQRT( EnergyGrad ) ) would be better, because it 
reaches exactly to the boundary-values, but maybe the boundary-values are reached very seldom 
and a subtler structuring around zero would be more important. 

This depends how often the boundaries are reached and how much energy-gradients supply small 
values. Maybe the naked result-value (Energy jafter) has to be weighted stronger and a valuation of 
the gradient alone is not sufficient. Moreover it had to be considered how much and which further 
registers are concerned beneath the energy-register and which and how much types of operations 
were executed, etc., and finally the execution-time of the energy-valuation-function itself. 
Therefore the energyspecific valuation-system has to be rarefied and adapted (like the valuation- 
system of intelligent biological life forms). 

Using dynamic embedded [PL/]SQL the changing and reparsing of the as string stored valuation- 
function no problem. Because of the execution-speed and the possibility of implementation of 
earlier programming-aim solutions the energy-valuation-function should be used in machine-code 
prospectively. 

The task of the amelioration of the energyspecific valuation-function is done, like the programming- 
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aim specific one, after every fulfilling of a programming-aim. 
Valuation-system and valuation-results are always reflexively. 

1.3.8 Reaching Seff-Consciousness, Reproduction and Evolution: 

Through the process of self-healing on pain/damage the program knows its location in memory. It 
now has the possibility to check out the effects of its own opcodes one after another, then 
consecutive opcode-combinations etc., and when it finally knows the effect of its total length, it'll 
reach self-consciousness and then has the possibility to reproduce itself and to ameliorate itself 
awarely while reproduction using its acquired knowledge (p.e. by removing the incommodious 
decrementing of the energy-register). 

The intelligent conscious-varying reproduction is much more preeminenced than the biologic- 
genetic one, because the latter only refers to existing genes/DNA, while the AC-program can vary 
itself by changing and extending its code intentionally using its "experience of life" . 

1.4. Conceptual Formulation of the Programming -Aim and Examples of Achievement 

To the AC-program an arbitrary programming-aim is challenged by giving one or more criterions in 

ADT .aim fulfilled ' Flag Function, by which it can check out, if it solved the task. 

Its job is it now to develop a program, which solves the problem for all initial-conditions. 

1.4. 1 Example 1: Developing a Program to compute the average: 

A very simple but easy to comprehend job for the AC-program could be: "write a program that 
computes the average over two integer-variables". 

The AC-program fulfills this task, if the difference between the result and the lower number is 
equal to the difference of the higher number and the result, and this is functioning for any arbitrary 
input-numbers. 

But the AC program doesn't know the instruction-set of the processor - it knows now only the 
opcodes which caused no damage and no fatal exception and it knows the opcode-effects in 
reference to the different initial-conditions. 

Through corruption-selfhealing or the energy-register it already knows easiest abandonments like 
"execute an action which causes no pain" or "execute an action which makes me saturated". 
For attaining economic programming-aims, it now needs valuation-variables, which reveals answers 
to the following questions: 
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a. ) How much nearer or farther away from the programming-aim took me the last added opcode- 

combination (that every added single opcode of it may cause opposite effects is irrelevant). 

b. ) How many processor clock-cycles needed the solution-program. 

c. ) How many bytes long is my program and how many opcodes are included ? 
These answering variables (CBT-table-columns) are: 

aim valuation ; cycles of execution ; OpCode length or Jump. 

The input-variables in the example-task could be in the first two data-registers (EAX n , EBX n 

respectively DO^DI^ respectively GPRO v , GPR^), here RO and R1 . 

The return-value should be the third data-register (ECX^ | 02^1 GPF^y), here R2. 

If the task is solved for arbitrary input-vaiues, the program is ready, because it's function. 

If there are more than one solution, the one is chosen which needs less clock-cycles. 

The task-specific aim-fulfilled valuation-function, which computes OLT .aim valuation is conse- 
quently in this example: 

A DT . aim fulfilled Flag Function ( average of RO and R1 ) = { (R2-R0) = (R1 -R2) } 
Here the problem could occur, that one input-value is even and the other one is odd, which means 
that this input-combination would have no solution. To implement that the aim fulfilled Flag- 
Function should be enhanced for integer-variables: { (R2-R0) = (R1-R2) | | (R2-R01 + 1 =(R1-R2) }. 
The AC-program will find several solution-programs and takes the one with the least needed clock- 
cycles. 

A possible solution would be in CBT(3): MOV R0,R2 ; ADD R1 r R2 ; SHR R2 

(... naturally in machine-code of the used processor - using a Pentium that would be the 48-bit- 
number #$89C2.01 CA.D1 EA, using a Motorola that would be #$2400.D282.E2C2 and using a 
PowerPC (RISC) a 96-bit-number would be the solution). 

1.4.2 Example 2: generation of a programs for computation of the cube-root: 

A further easy development-task would be "write a program that returns the cube-root of a FFP 
(fast floating point) number"; the input-variable should be RO (EAX„) and the output-variable R3 
(EBX % ). 

The AC-program fulfills this task, if the result multiplied with its square is equal to the input-value 
(and this is valid for all initial conditions): 

=> aim fulfilled Flag Functionf cube root ) = { (R3*R3*R3) = RO } (-^-naturally in FFP-multiplic.) 
A single command like the square-root (FSQRT) doesn't exist for the cube root. 
The solution-program could be in CBT(8) using a Pentium II as follows: 

Op1(16b): MOV CL,3 ;ECX = $????:0003 [1011.0001:0000.0011] 

Op2(16b): FLD1 ;ST(0)=1.0 [1101.1001:1110.1000] 



■ 24 - 



Op3(16b): FIDIV CX 

Op4(16b): FLD EAX 

Op5(16b): FYL2X 

Op6(16b): FLD1 

Op7(16b): FSCALE 

Op8(16b): FST EBX 



ST(O) = V 3 

ST(0) = RO ;ST(1) = V 3 
ST(0) = V 3 log 2 (RO) 



[1101.1110 
[1101.1001 
[1 101.1001 



1 1 1 1.0001] 
1 100.0000] 
1111.0001] 
1 1 10.1000] 
1 1 1 1.1 101] 
1 101.101 1] 

shown in 



ST(0) = 1.0 ;ST(1) = V 3 !og 2 (R0) [1101.1001 
ST(0) = 1.0*2 A [V 3 log 2 (R0)] [1101.1001 
EBX = 2 A [V 3 log 2 (R0)] [1101.1001 
(... naturally only the second of these columns as a 1 28-bit-number with the bits set 
the last column.) 

Hexadecimal that would be: B1 03.D9E8.DEF1 .D9C0:D9F1 .D9E8.D9FD.D9DB. 

This would be a possible solution-number ( = program) for the given task (there 1 re surely shorter and 
faster solutions too). 



1.5. Needed Hard-disk-Space and Oblivion 

In both examples 1 6-bit-opcodes would be sufficient, but it's obvious, that large programming- 
aims would need much hard-disk space. Therefore the AC-program has to forget unimportant or 
error-causing opcode-combinations. 

1.5. 1 Table sizes: 

1ST, RIT and CIT need neglectable disk-space. 

Theoretically there could be s/ze(0BT) = 2 32 * X bytest column(i) ) = 485 GB, but also on a 
RISC processor never all 32-bit-combinations are used as a valid opcode and realistic are as an 
average on RISC processors about 28 bits => 30 GB and on CISC processors about 20 bits 1 1 8 
MB [on latter the most are 16 bit-opcodes, there're a few 8-Bit- and several 24- and 32-bit- 
opcodes, and the ones which are longer 32-bits are not used (we don't need memory-to-memory- 
operations for example and the functionality of one long opcode can be substituted by two or more 
shorter opcodes). 

The 62 initial conditions can cause s/ze(OLT) = 2 [2 °- 281 * 62 * Z bytes( column(i) ) = 3 GB 
(CISC) up to 832 GB (RISC) and s/ze(ORT) could reach the same quantity, considering that one 
opcode mostly pertains one destination- and one source-register (unitary ones use only the 
destination-register and a few seldom opcodes use 3 or more registers). But there could be many 
effect-belonging Operation BitCodes, which would increase the tablespace dramatically, if it 
wouldn't be compensated by the many opcodes which cause an exception, where less information 
has to be stored. 

A much larger problem is the exponential growth of the CxT(i), because every i multiplies the 
needed tablespace by factor of 2 [20 - 281 . But this is exact that what should be compensated by the 
dynamic valuation-system. It decreases its knowledge-absorption tolerance referable to the 
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remaining hard-disk space: So opcode-combinations with least CBT(i). max _aim valuation or 

.avg aim valuation are forgotten and so will not be combined with other opcodes. 

Although if the demand of hard-disk space arrears large, this is no problem in near future. Also the 

according to the combination-possibilities and table-sizes increasing calculation-times are 

compensated by larger and faster becoming hard-disks and the increasing efficiency of the 

processors. 

1.5.2 Oblivion: 

Like all intelligent life-forms, the system has to forget unimportant and less important informations, 
because 

a. ) the disk space is limited, and 

b. ) data access time becomes slow on very large data-tables. 

Therefore after every satisfactorily achievement of objectives, when a new programming-aim is 
given, the ELT and all CxT(i)-tables over a remaining disk-space dependant i are deleted, and the 
opcode-combinations in the remaining CxT(i) are revalued referable to the new programming-aim 
and forgotten opcode-combinations are added, if they're valuable for the new aim and the higher 
CxT(i) are recreated dynamically. 

1.6. Becoming Conscious 

Through try and error the program learned what effectuated every action and what are the effects 
of which sequence of actions. 

Through corruption-healing (if own code was overwritten in RAM) it had to repair its code and so it 
knows its position in memory. 

If it once knows the effect of its own machine-code, it gets self-consciousness and has the ability 
to reproduce its code and to ameliorate it while reproduction. 

Through the so initialised evolution the AC becomes complexer and better and will be able to solve 
larger and larger programming-tasks in future. 

1.7. Presentment of the Economic Advantages 

Here a totally new area of using a computer is presented. While normally in a computer run by man 
generated programs, which execute user-controlled applications, the AC-program itself develops 
and executes programming-aim oriented routines, which can later embedded into a large 
application. 
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The demand for software-development is worldwide much larger than the human potential of 
developers. 

A system which learns to write programs itself has the capability to solve smaller development- 
tasks, and will in future, after several evolution-steps, have the capability to develop complex 
programs as the solution of large tasks too, if it has got enough hard-disk space. 

The programmers will not have to develop all the routines they need - they order the routine from 
the AC-program and embed it into their application. So the companies can finish and sell their 
software-products earlier. 
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CLAIMS: 

What is claimed is: 

1 . A method using a computer which automatically generates and executes machine-code, 
comprising the steps of 

a) preventing the multi-tasking of the operation-system, by setting the interrupt-mask of the 
processor to NMI or using a multitasking-disable-routine of the operating-system; 

b) capturing the processors exception-vectors by own analysis-routines; 

c) generating normal numbers and writing them into memory; 

d) backing up the current values of the processors registers; 

e) positioning the instruction-pointer = program-counter to the generated number in memory and 
executing the number like it would be a processor-opcode; and 

f) analysing the effects of this opcode-like execution of the number and storing the analysis- 
results, p.e. in a database. 

2. A method according to claim 1, wherein said step of (d) "backing up the current values of the 
processors registers" comprising the steps of: 

a) not only saving them for a later comparison but setting them to predefined initial conditions; 

b) setting them not only one time but several times to many different predefined initial 
conditions which means several executions of one number in step (e) by these different 
initial conditions for to have a more efficient analysis-determinations of possible number- 
execution-effects in step (f). 

3. A method according to claim 2, wherein said step (1f) "analysing the effects of this opcode-like 
execution of the number" further comprising the step of determining the number=opcode's 
mnemonic and its related source- and destination-registers by regarding all execution-effects of 
every initial condition. 

4. A method according to claim 3, wherein said step (1c) "generating normal numbers and writing 
them into memory'' comprising the steps of combinations, which means: 
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a) taking one number which analysed results are already stored and appending another number 
with stored analysis-results to analyze the execution-effects of this two-number-combination 
and store the result. 

b) combining 2-number-combinations, which effects are already analysed, with a further 
analysed number and analysing and storing the analysis-results of the effects of these 3- 
number-combinations. 

c) combining a 3-number-combination, which effects are already analysed, with a further 
number, which effects are already analysed, or combining two 2-number-combinations, 
which effects are already analysed, and analysing and storing the effects of these 4-number- 
combinations. 

d) combining larger combinations, which effects are already analysed, with numbers or 
combinations, which effects are already analysed, and analysing and storing the effects of 
these larger combinations. 

5. A method according to claim 4, further comprising the step of using only combinations for 
further use, which got a positive value from a valuation-function, which appraises the 
valuability of the combination in reference to reaching a pregiven programming-aim, not causing 
fatal exceptions, not overwriting exception-vectors or the program, avoiding to use forbidden 
registers or extensive writes to memory or large jumps, etc. 

6. A method according to claim 5, further comprising the step of valuating and changing the 
valuation-function of the dynamic valuation-system by a meta-valuation-function valuating the 
results of the valuation-function according to clustering to boundary-values, low-values, other 
fixed values, etc., and then revaluating the results of the new valuation-function. 

7. A method according to claim 4, further comprising the step of implementing calls to operation- 
system routines which are offered in a table with entrance-address and source- and destination- 
registers. 

8. A method according to claim 7, further comprising the step of using only calls and 
combinations for further use, which got a positive value from a valuation-function, which 
appraises the valuability of the call-combination in reference to reaching a pregiven 
programming-aim, not causing fatal exceptions, not overwriting exception-vectors or the 
program, avoiding to use forbidden registers or extensive writes to memory or large jumps, etc. 

9. A method according to claim 8, further comprising the step of offering the disassembly of the 
solution-programs which solved the programming-aim. 



10. A method using a computer which automatically generates and executes machine-code, 
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comprising the steps of 

a) capturing the tasks= processes exception-vectors by own analysis-routines; 

b) generating normal numbers and writing them into memory; 

c) backing up the current values of the processors registers; 

d) positioning the instruction-pointer = program-counter to the generated number in memory and 
executing the number like it would be a processor-opcode; and 

e) analysing the effects of this opcode-like execution of the number and storing the analysis- 
results, p.e. in a database. 

1 1. A method according to claim 10, further comprising the steps of modelling the following basic 
needs: 

a) "no pain", where pain means damage to the own program, which is an overwriting of the 
own machine-code, which is recognised by comparing the programs checksum after every 
execution of a number or number-combination, and repairing damaged parts of the own 
machine-code from a duplication, which causes a decrementation of the energy-register for 
every damaged opcode of the own program which now has to be copied for reparation; and 

b) "no hunger ", where hunger means the imminent loss of energy, where energy is modelled 
by the value of a predefined register, which causes negative effects on low values like 

- the loss of the capability of appraising combinations referable to the programming aim on 
low values of the energy-register, 

- mistakes on the valuation of the combination-execution concerning the source-registers on 
very low values of the energy-register, 

- the loss of the capability of self-repairing on "pain" on extreme low values of the energy- 
register, 

- a hardware-dependant decreasing of the power supply of the RAM (p.e. by increasing a 
resistor) on two times in series extreme low values of the energy-register, 

- a hardware-dependant decreasing of the power supply of the processor (p.e. by increasing 
a resistor) on three times in series extreme low values of the energy-register, 

and this energy-register is decremented after every action, where action means the 
execution of a number. 



12. A method according to claim 10, wherein said step of (10c) "backing up the current values of 



the processors registers" further comprising the steps of 



a) not only saving them for a later comparison but setting them to predefined initial conditions; 

b) setting them not only one time but several times to many different predefined initial 
conditions which means several executions of one number in step (10d) by these different 
initial conditions for to have a more efficient analysis-determinations of possible number- 
execution-effects in step (10e). 

13. A method according to claim 12, wherein said step (10e) "analysing the effects of this opcode- 
like execution of the number" further comprising the step of determining the number=opcode's 
mnemonic and its related source- and destination-registers by regarding all execution-effects of 
every initial condition. 

1 4. A method according to claim 1 3, further comprising the step of valuating the effects of the 
execution of the number in reference to its basic needs, which means positive values for 
numbers, which cause no pain or increase the energy-register and negative values for numbers 
which cause above defined "pain" or "hunger". 

15. A method according to claim 14, further comprising the step of combining numbers and 
executing these combinations and valuating the effects of the executions of these 
combinations. 

16. A method according to claim 15, comprising the step of running several of these said programs 
as an extra process=task. 

17 A method according to claim 15, comprising the step of using a network topology where on 
two or more of the networked computers is running one of these programs. 

18. A method according to claim 14, further comprising the step of analysing a pregiven code by 
executing larger getting sequences of it instead of executing number-combinations, for to 
evaluate the effects these code-sequences or at least of the complete program. 

19. A method according to claim 18, further comprising the step of improving the analysed code in 
the direction of a pregiven programming-aim. 



20. A method according to claim 15, further comprising the step of implementing calls to 
operation-system routines which are offered in a table with entrance-address and source- and 
destination-registers. 
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21. A method according to claim 20, further comprising the step of using only calls and 
combinations for further use, which got a positive value from a valuation-function, which 
appraises the valuability of the call-combination in reference to reaching a pregiven 
programming-aim, not causing fatal exceptions, not overwriting exception-vectors or the 
program, avoiding to use forbidden registers or extensive writes to memory or large jumps, etc. 
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ABSTRACT OF THE DISCLOSURE: 



A method for generating a simple kind of computer based artificial consciousness, which means to 
give a in a computer running invention-pursuant program the capability to act and to know the 
effects of its actions and to plan further actions consciously. This is realized by giving the 
computer the capability to program its processor by its own and to plan that self-programming 
targeted. This works, because the computer learns to program in machine-code by its own and it 
has got a dynamical valuation system to weight if its actions are useful or not. Further basic needs 
like "no pain" and "nohunger" are modelled to make it act to fulfill its basic needs. It has also the 
capability to solve a pregiven by several formulas determined programming aim, which means to 
develop logical programs which then can be implemented by users into their projects. 



DRAWINGS: 
3.1 Relational Database of the AC-knowledge: 
3. 1. 1 ER-Diagram of the AC-Database: 
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3. 1.2 Tables of the AC-Database: 



Register-ldentification-Table: [RIT: every processor-register gets a Reg. ID and a Reg. BitCode] 
column: datatype value-range meaning: 



Register ID (PK) 


signed byte 


-128.. 127 


0 = Flags-reg., = data-reg., adr.reg., adr.reg.- 
destinations, FFP-reg., control-reg., debug-reg., etc.; 
neg.reg.lD = exception-vector-nr. (no processor-reg.) 


Register BitCode 


number 


0..2128.-I 


2 A Register ID, 0 if Register ID is negative. 


Register_type 


chard) 


1 Byte 


type of register: # = flags-reg., D = data-reg., 

A = address-reg., V = adr. -reg. -destination, E = excep 

tion-vector, etc. (processor dependant). 


Register number 


byte 


0..127 


current number of the {register-type}-reg\sters. 


RegisterDescription 


varchar2(32 


<32 Bytes 


optional description of the register[-reference]. 



Fig.2a 



Register ID 


Register BitCode 


Register type 


Register number 


Register Description 




0 


E 




{for all Exception-Vectors} 


-8 


0 


E 


8 


Privilege-Violation Exception 




0 


E 




{for all Exception-Vectors} 


0 


1 


# 


0 


Status-Register (= EFIagsJ 


1 


2 


D 


0 


Data-Register DO 




4 


D 




{for all Data-Registers D1-D6} 


8 


8 


D 


7 


Data-Register D7 


9 


16 


A 


0 


Address-Register AO 






A 




{for all Address-Registers A 1-A6} 


16 


65536 


A 


7 


Address-Register A7 ( = USP/) 


17 


131072 


V 


0 


Destination of Address-Register AO 






V 




{for all Adr. -Reg. -Destinations A1-A6} 


24 


16777216 


V 


7 


Destination of Adr. -Reg. A7 [ = (USP)] 


25 


33554432 




0 


Destination before Adr. Reg AO [- 
(AO)] 






V 




{for all Adr.Reg.-Dest. before A 1-A6} 


32 


$1.0000.0000 


V 


7 


Destination before Adr. Reg A7 [-(USP); 


33 


$2.0000.0000 


F 


0 


Floating-Point Data-Register FPR0 










{for all further Registers} 



Fig. 2b (RIT in a Motorola-Example) 



Initial-Conditions-Table: [ICT: every register(-reference) gets 62 initial conditions] 
column: datatype value-range meaning: 



IniConNr 


(PK) 


signed byte 


-31. . + 30 


number of the initial-condition combination 


Register ID 


(PK) 


signed byte 


0..127 


see RIT 


Register Value 


integer 


0..2 32 -1 


value of the register(-reference) on actual IniConNr 



Fig. 3a 



Therefore 62*#registers test-values are generated, p.e. using the following function: 

Register_Value( IniConNr, RegisterJD ) = SGN( IniConNr ) * INT( 2 A ABS(lniConNr/2) + 1 / 2 ) 

+ prime number( 3* Register ID ) or similar. 

, where primenumber(O) = 0 and prime number(-n) = -prime number(n) 

[no 2 equal register(-destination)-values] 

Fig. 3b 
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Operation-ldentification-Table: [PIT: every processor-operation gets an Oper.lD and an Oper.BitCode] 
column: datatype value-range meaning: 



Operation ID (PK) 


signed byte 


-1..63 


bit of the Calculation BitCode - see table below. 


Operation BitCode (FK) 


number 


0.. 2 128-1 


2Xalculation ID - see table below. 


Operation Type 


char(5) 


5 Bytes 


5 characters-code of the operation-type, see Fig. 4c 


Operation Mnemonic 


char(5) 


5 Bytes 


abbreviation of the operation - see table below. 


OperationDescription 


varchar2(32 


<32 Bytes 


optional description of the operation - see table below 
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Operation ID 


Operation BitCode 


Operation Type 


Op. Mnemonic 


Operation Description 


-1 


0 






??? 


unknown operation 


0 


1 




111? 


TST 


set flags in dependence of reg.(-ref.) 


1 


2 




112 ! 


NEG 


negation [ amount 


2 


4 




112 ! 


NOT 


bitwise inversion 


3 


8 




102 


MOVI 


const, integer— >register(- reference) 


4 


1 6 




112 + 


ADDI 


add constant integer 


5 


32 




112- 


SUBI 


subtract constant integer 


6 


64 




113* 


MULI 


multiply constant integer 


7 


128 




123/ 






8 


256 




113% 


MODI 


resTonnte^rdivi 


9 


512 




112* 


shli 


Inte er times a duplication 


10 


1 .024 




112/ 


— slii 


integer-times a halvation 


1 1 


2.048 




112 1 


— oil 




1 2 


4.096 




I12& 


ANDI 


dea^bit^not set^n ^ con'st^nte er 


13 


8.1 92 




112? 


BTSTI 


check if tnt thbit Is setiTre "( refT 


14 


1 6.384 




112? 


CMPI 


reg^-ref Tcompariso^withtnteger — 


15 


32.768 


1122 


MOV 


move src . -reg . ( ref . ) — >d est . reg ( ref . ) 


16 


65.536 


1122 + 


ADD 


addition of register(-reference) 


17 


131.072 


1122- 


SUB 


subtraction of register(-reference) 


18 


262.144 


1123* 


MUL 


multiplication of register(-reference) 


19 


524.288 


1133/ 


DIV 


division by register(-reference) 


20 


1.048.576 


1133% 


MOD 


rest of division by register(-ref.) 


21 


2.097.152 


1122* 


SHL 


register(-ref.)-times a duplication 


22 


4.194.304 


1122/ 


SHR 


register(-ref.)-times a halvation 


23 


8.388.608 


1122 I 


OR 


set bits set in of register(-reference) 


24 


16.777.216 


II22& 


AND 


clear bits not set in register(-ref.) 


25 


33.554.432 


1121? 


BTST 


check if reg. (-ref .)-th bit is set 


26 


67.108.864 


1121? 


CMP 


compare reg. (-ref. )1 with reg. (-ref. )2 


27 


134.217.728 


:P00. 


JMP 


add integer to PQ/EIP^ (=jump to) 


28 


268.435.456 


CP1 . < 


JLT 


jump if CMP< 


29 


536.870.912 


CP1 ! > 


JLE 


jump if CMP < 


30 


1.073.741.824 


CP1.= 


JEQ 


jump if CMP = 


31 


2.147.483.648 


CP1 ! < 


JGE 


jump if CMP > 


32 


4.294.967.296 


CP1 ! = 


JNE 


jump if CMP * 


33 


$2.0000.0000 


CP1.> 


JGT 


jump if CMP> 


34 


$4.0000.0000 


CP1 !< 


JPL 


jump if > 0 


35 


$8.0000.0000 


CP1.< 


JMI 


jump if <0 


36 


$10.0000.0000 


CP1 . ~ 


JCS 


jump if carry-flag is set 


37 


$20.0000.0000 


CP1 ! " 


JCC 


jump if carry-flag is clear 


38 


$40.0000.0000 


CP1.~ 


JVS 


jump if overflow is set 


39 


$80.0000.0000 


CP1 ! ~ 


JVC 


jump if overflow is clear 


40 


$100.0000.0000 


CP2.< 


DJMP 


decrement and jump if reg. ( ref.) <0 


41 


$200.0000.0000 


PS1. . 


CALL 


PQ/EIP^-fUSPy/ESPJ ; + JUMP 


42 


$400.0000.0000 


SP11 . 


RET 


(USP u /ESP a )+ ^PC^/EIP^ 


43 


$800.0000.0000 


. I . . . 


I??? 


unknown integer-operation 


44 


n ooo.oooo.oooo 


. F. . . 


F??? 


unknown floating-point-operation 
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45 


520O0.O000.O0OO 


FF09 


FINIT 


initialise floating-point-unit 


46 


^4000.0000.0000 


FI12 


FIST 


store float. point-reg.-»integer-reg. 


47 


>8000. 0000.0000 


IF12 


FILD 


load integer-reg.-»floating-point-reg. 


48 


$1.0000*2 32 


IF22 + 


FIADD 


floating-point add constant integer 


49 


$2.0000*2 32 


IF22- 


FISUB 


floating-point subtract const.integer 


50 


$4.0000*2 32 


IF22* 


FIMUL 


floating-point multiply const.integer 


51 


$8.0000*2 32 


IF22/ 


FIDIV 


floating-point divide by const.integer 


52 


$10.0000*2 32 


IF21? 


FICMP 


float.pt. compare with integer-^flags 


53 


$20.0000*2 32 


:F02 


FLD# 


load constant to floating-point-reg. 


54 


$40.0000*2 32 


.F12 ! 


FABS 


build floating-point amount 


55 


$80.0000*2 32 


FF12 


FLD 


copy floating-point-register 


56 


$100.0000*2 32 


FF22 + 


FADD 


add 2 floating-point-register 


57 


$200.0000*2 32 


FF22- 


FSUB 


subtract 2 floating-point-register 


58 


$400.0000*2 32 


FF22* 


FMUL 


multiply 2 floating-point-register 


59 


$800.0000*2 32 


FF22/ 


FDIV 


divide one float.pt. reg. by another 


60 


$1000.0000*2 32 


. F12@ 


FSQRT 


square-root of a floating-point-reg. 


61 


$2000.0000*2 32 


.F12@ 


FSIN 


floating-point-sine 


62 


$4000.0000*2 32 


.F12@ 


FCOS 


floating-point-cosine 


63 


$8000.0000*2 32 


.F12@ 


FATAN 


floating-point arc-tangent 


64 


$1* 2 48 


FF22* 


FEXP2 


y: = y*2 x (anykind of exp.-func.) 


65 


$2*2 48 


FF22/ 


FLOG2 


y: = x*log?y (any kind of logarithm) 


66 


$4*2 48 


FF21? 


FCMP 


compare 2 float.-point-reg.->Flags 


67 


$8*2 48 


$111 


SMOV 


move from a special Register 


68 


$10*2 48 


I$ll 


MOVS 


move to a special Register 













Fig. 4b 

... using the following operation-type character-codes: 



1st char. 


= source , 2nd char. = dest. : 




= unknown, ambitious letter for all possible following 








= nothing 








= constant number 






r 


= integer-register-[reference]-value 






F 


= floating-point register 






C 


= condition-code register (last byte in EFIags^/SR w ) 






P 


= instruction-pointer / program-counter (ElP^/PCy) 






s 


= stack-pointer reference-value 








= comparison-operation ^flags 






$ 


= a special-register like flags-, control-, debug-, ... -reg. 






I 


= logical NOT for comparison in the 4th field 


3rd char. 


= number of source-registers: 




including destination reg., if it's used as source-reg. too 


4th char. 


= number of dest. -registers: 




including flags-register but without the instruction-pointer 


5th char. 


= effect of arithmetic: 




- unknown 








= none 








= amount | negation | bitwise inversion 






+ 


= addition 








= subtraktion 








= multiplication 






/ 


= division 






% 


= rest of division 






I 


= setting of bits (mostly bitwise OR) 






& 


= clearing of bits (mostly bitwise AND) 






@ 


= trigonometric- or exponential-function 






> 


= greater? (CC-flags dependant action) 






< 


= less? (CC-flags dependant action) 








= equal? (CC-flags dependant action) 








= carry? (CC-flags dependant action) 








= overflow? (CC-flags dependant action) 


Fig. 4c 
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OpCode-Register-Table: [ORT - by opcode id, initial-conditions concerned registers and the effect] 
column: datatype value-range meaning: 



OpCode (PK) 


integer 


0..2 32 -1 


complete instruction, truncated if > 4 bytes 


IniConlMr (PK) 


signed byte 


-31. .30 


current number of the used initial conditions 


Register ID dest (PK) 


signed byte 


0..127 


one by execution concerned destination-reg. (see RIT) 


Register ID source (PK) 


signed byte 


-1,0..127 


-1 or one possible source-register (see RIT). 


value before change 


integer 


0..2 32 -1 


register(-reference)-value before it was changed 


value after change 


integer 


0..2 32 -1 


register(-reference)-value after changing 


gradient if unsigned 


signed byte 


-128.. 127 


before/after-gradient, when defined as unsigned 


gradient if signed 


signed byte 


-128.. 127 


before/after-gradient, when defined as signed 


value source 


integer 


0..2 32 -1 


value of a possible source-register(-reference) 


Operations BitCode 


number 


0..2 12 8-1 


bitmask, which flags all possible operations 
between this Register ! D dest / Register ID source 
-combination (p.e. 2 + 2 = 2*2 using same reg.'s). 
Values see CIT, calculation see fig. 19. 



Fig. 5 



For every register- or register-reference-modification of the same opcode-execution one entry is 
generated, which gives information about the register(-reference)-values before and after the 
execution and further information about the degree of changing and with it a hint to a possible 
operation and a possible source-register which were used. (Packed-, nibble-, or BCD-operations are 
not considered.) 

The last address-register is the stack-pointer. The last data-register is the "energy"-register. 

An address-register can be every register which value can be a pointer to memory which 

destination can be accessed using this register as a reference. 

Several registers can be modified simultaneous - therefore this additional 1:n table, where 
Register J D dest means the identity of the changed register. Sometimes many register(-references) 
could be the source for one operation - this quantum increases through the sum over all possible 
operations. 

Therefore the following tables identify the used opcode and the concerned register(s): 



OpCode-Learn-Table: [OLT - ascertained effect of the opcode using the concerning initial conditions] 
column: datatype value-range meaning: 



OpCode (PK) 


integer 


0..2 32 -1 


complete instruction, truncated if > 4 bytes 


IniConNr (PK) 


signed byte 


-31. .30 


number of used initial condition 


active ChkSum corrupt 


boolean 


1 10 


flag: checksum of active AC-program changed 


inactive ChkSum corrupt 


boolean 


1 |0 


flag: checksum of inactive AC-program changed 


Exception Vect changed 


signed byte 


-128. ..0 


Register ID of the (first) overwritten exception-vector 


multiple Exc Vect chg 


boolean 


1|0 


more than one exception-vector was overwritten 


Processor Mode Changed 


boolean 


no 


flag: processor-mode changed (p.e. trace cleared) 


Number of Exception 


byte 


0..N+1 


exception-number [0: = no exception] (if 0 = exc. : + 1 ) 


OpCodeJengthorJump 


signed byte 


-128. .127 


ElPyPC^ after execution - EIP^/PC^ before execution 
-128=$FF=long back-jump, 1 27= $7F=long forward j. 


CCR before execution 


byte 


0..255 


CC-flags, which could cause a jump. 


RegisterchangedBitCode 


number 


0..2 12 8-1 


£"2 A ORT. Register ID dest V ORT(opcode,lniConl\lr) 


RegistersourceBitCode 


number 


0..2 12 8-1 


£"2"0RT.Register ID source V ORT(opcode,lniConNr) 


maxOperationsBitCode 


number(19) 


0..2 12 8-1 


3 ORT. Calculation BitCode VORT(opcodeJniConNr) 


minOperationsBitCode 


number(19) 


0..2 128 -1 


^ORT.Calculation BitCode V0RT(opcode, IniConNr) 


time of execution 


integer 


0..2 32 -1 


deci-seconds after {20.9.1994, 0:00:00,0 o'clock} 


cycles of execution 


byte 


1..255 


clock-cycles the opcode-execution needed 


aim valuation 


signed byte 


-128.. 127 


aim-attaining-valuation using above initial-conditions 


gradient aim valuation 


signed byte 


-128. .127 


-"-difference to CLT( n-1, IniConNr ). aim valuation 



Fig.6 
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OpCode-Base-Table: fOBT - ascertains the effect of the opcode-execution from the initial conditions] 
column: datatype value-range meaning: 



OpCode (PK) 


integer 


0..2 32 -1 


complete instruction, truncated if > 4 bytes 


Execution counter 


byte 


0..255 


number of the OLT-entries until now 


FatalErrorcounter 


byte 


0..255 


number of the opcode-caused fatal errors until now: 
CheckSumcorrupt, Exception Vect changed, 
TraceBitcheared, Processor Mode changed, and 
the exceptions without Divide-Error, Overflow. 


low Error counter 


byte 


0..255 


number of divide-errors plus ouer/Toiv-exceptions 


Jump longOp probability 


signed byte 


-128. .127 


probability that it's a long opcode or a jump 


avg OpCpdeJump length 


signed byte 


-128.. 127 


average length of opcode or jump 


OpCode len unconfirmed 


boolean 


1 |0 


min. one divergence from above average exists 


avg cycles of execution 


byte 


1..255 


average by opcode-execution needed clock-cycles 


exec cycles unconfirmed 


boolean 


1..0 


min. one divergence from above average exists 


Register write probability 


signed byte 


-128.. 127 


probability: opcode writes into a register 


Register copy probability 


signed byte 


-128.. 127 


probability: opcode copies register 


Memory write probability 


signed byte 


-128.. 127 


probability: opcode writes into memory 


Memory copy probability 


signed byte 


-128.. 127 


probability: opcode copies memory 


Reg to Mem probability 


signed byte 


-128. .127 


probability: opcode copies reg. to adr.reg. -destination 


Mem to Reg probability 


signed byte 


-128.. 127 


probability: opcode copies adr.reg. -destination to reg. 


Multi Reg write prob 


signed byte 


-1 28. .1 27 


probability: opcode writes into more than one register 


Multi Mem write prob 


signed byte 




probability: opcode writes to many adr.reg. -destination 


Multi Reg to Mem prob 




128 127 


prob.: opcode copies >2 reg. to >2 adr.reg. -destination 


Multi Mem to Reg prob 


signed byte 


-1 28.. 1 27 


prob.: opcode copies >2 adr.reg. -destinations to >2 rec 


allRegdestBitCode 


number 


0..2128.-I 


*£TOLT. Register changed Bitcode V OLT(OpCode) 


cut Reg dest BitCode 


number 


0..2 128 -1 


£"0LT. Register changed Bitcode V OLT(OpCode) 


all Reg source BitCode 


number 


0..2 128 -1 


S OLT. Register source Bitcode V OLT(OpCode) 


cut Reg source BitCode 


number 


0..2 128 -1 


4"OLT.Register source Bitcode V OLT(OpCode) 


maxOperationBitCode 


number 


0..2 128 -1 


£"OLT.max Operation BitCode V OLT(OpCode) 


minOperationBitCode 


number 


0..2 128 -1 


C OLT. min Operation BitCode V OLT(OpCode) 


allOperationBitCode 


number 


0..2 128 -1 


S'OLT.min Operation BitCode V OLT(OpCode) 


cutOperationBitCode 


number 


0..2 128 -1 


£ OLT. max Operation BitCode V OLT(OpCode) 


max write value 


integer 


0..2 32 -1 


maximum of all destination-values 


min write value 


integer 


0..2 32 -1 


minimum of all destination-values 


avg write value 


integer 


0..2 32 -1 


average over all destination-values 


max write gradient 


integer 


0..2 32 -1 


maximum gradient of the changed value 


min write gradient 


integer 


0..232-1 


minimum gradient of the changed value 


avg write gradient 


integer 


0..2 32 -1 


average gradient of the changes value 


evaluated source Register 


signed byte 


-1,0. .127 


ascertained source-register-ID (after OBT-evaluation) 


evaluatedsourceNumReg 


signed byte 


-128, -1, 
0..127 


-1 28 = LOB means source-constant; 0.. 1 27 means a 
further source-register ID; none = -1 (after OBT-eval.) 


evaluated dest Register 


signed byte 


-1, 0..12: 


ascertained destination-register after OBT-evaluation 


evaluated dest Register2 


signed byte 


-1, 0..12; 


possible 2nd dest.-reg. after OBT-evaluation or flags- 
reg. (2 real dest.-reg. => flags-reg. not appreciated). 


evaluated Operation ID 


signed byte 


-1,0..63 


ascertained operation-ID (after OBT-evaluation) 


Confirmation counter 


byte 


0..255 


counter: same effects on other initial conditions 


max aim valuation 


signed byte 


-128.. 127 


max. valuability of the opcode for aim-attaining 


avg aim valuation 


signed byte 


-128. .127 


average valuability of the opcode for aim-attaining 


maxgradaimvaluation 


signed byte 


-128. .127 


max. gradient of aim-attaining in relation to the by 1 
shorter opcode-combination of the last CBT(i-1). 


avg grad aim valuation 


signed byte 


-128.. 127 


average gradient concerning above -"- 



Fig. 7 



Datatypes: Boolean 1 Bit, BCD/Nibble 4 Bit, Byte/char(1) 8 Bit, Word/short 16 Bit, DWord/lnteger 32 
Bit, QWord/number(19) 64 Bit, number/number(38,0) 128 Bit (38 digits = 16 bytes), varchar2(N) 
string of variable length with max.N characters, long very long string with max(longDef) characters. 
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The following combination-tables are created dynamically - they have the same non-PK-columns, 
like the OBT respectively OLT respectively ORT, but for every additional number of combinations a 
further more opcode in the PK: 



Combination-Register-Table: [CRT(i), i= number of opcodes in the combination, CRT(1)=ORT] 
column: datatype value-range meaning: 



OpCode 1 (PK) 


integer 


0-232-1 


opcode #1 (first of the combination) 


{for all OpCodes} (PK) 


all integer 


0-2 32 -1 


{for all opcodes from #2 up to N-1 } 


OpCode N (PK) 


integer 


0-232-1 


opcode#N {last of the combination) 


IniConNr (PK) 


signed byte 


-31. .30 


current number of the used initial conditions 


Register ID dest (PK) 


signed byte 


0..127 


one by execution concerned destination-reg. (see RIT) 


Register ID source (PK) 


signed byte 


-1..127 


-1 or one possible source-register (see RIT). 


{same non-PK columns 
like in the Opcode- 
Register- Table. } 


see above 


see 
above 


same non-PK columns like ORT. 



Fig.8 



Combinations-Learn-Table: [CL T(i), i= number of opcodes in the combination, CL T(l) = PL T] 
column: datatype value-range meaning: 



OpCode 1 (PK) 


integer 


0-2 32 -1 


opcode #1 (first of the combination) 


{for all OpCodes} (PK) 


all integer 


0-2 32 -1 


{for all opcodes from #2 up to N-1 } 


OpCode IM (PK) 


integer 


0-2 32 -1 


opcode#N (last of the combination) 


IniConNr (PK) 


signed byte 


-31. .30 


current number of the used initial conditions 


1 {same non-PK columns 
\like in the Opcode-Learn- 
\ Table.} 


see above 


see 
above 


same non-PK columns like OL T. 



Fig.9 



Combinations-Base-Table: [CBT(i), i= number of opcodes in the combination, CBT(1)=OBT] 
column: datatype value-range meaning: 



OpCode 1 (PK) 


integer 


0-2 32 -1 


opcode #1 (first of the combination) 


{for all OpCodes} (PK) 


all integer 


0-2 32 -1 


{for all opcodes from #2 up to N-1} 


OpCode N (PK) 


integer 


0-2 32 -! 


opcode#N (last of the combination) 


{same non-PK columns 
like in the Opcode-Base- 
Table.} 


see above 


see 
above 


same non-PK columns like OBT. 



Fig. 10 

| CBT(max.) = CPT = Combination-Plan-Table = point of origin of the outcoming program. 



Programming-aim and valuation-function tables: 
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Aim-Solution-Table: [AST - solutions of all programming-aims] 
column: datatype value-range meaning: 



Aim ID (PK) 


short 


0.. 65535 


Identifier of the programming-aim 


Solution Nr (PK) 


byte 


0..255 


number of the solution-program 


aim Program 


long 


String 


opcode-combination of the solution here as a string 


Program length 


short 


1.. 65535 


length of the solution-program in doublewords 


cycles of execution 


integer 


1..2 32 -1 


execution-time in clock-cycles of the solution-program 


used Registers BitCode 


number 


1..2 12 8-1 


bitcode of all in the solution-program used registers 


used Operations Bitcode 


number 


1..2 12 8-i 


bitcode of all in the solution-program used opcodes 


used aim Valuation Func 


signed short 


0..32767 


identifier of the used aim-distance valuation-function 



Fig. 11 



Aim-Description-Table: [APT - identification and description of programming-aim] 
column: datatype value-range meaning: 



Aim ID (PK) 


short 


0.. 65535 


Identifier of the programming-aim 


aim Description 


varchar2(32 


<32 Bytes 


description of the programming-aim 


used Processor Mode 


integer 


0-2 32 -1 


flags above CC | control-register-bits 


all dest Register BitCode 


number 


1..2 12 8-1 


bitcode of all output-registers in this task 


ali source Register BitCode 


number 


1..2 12 8.-| 


bitcode of all input-registers in this task 


unused Regiser BitCode 


number 


1 ..2128.-, 


bitcode of all registers which should not be used 


un usedO perationBitCode 


number 


0..2128-! 


bitcode of all opcode-IDs which are not allowed to 
use in this task (default = $0000.0000:0000.0000) 


airn_implement_solutions 


long 


String 


string of the AimJD's (words) of earlier solutions, 
which could be implemented here. 


aim fulfill valuation mode 


boolean 


0 1 1 


mode of aim-valuation: 0 = SQL ; 1 = machine-code 


aim fulfilled Flag Function 


varchar2(99; 


<99 Bytes 


boolean aim-attained recognition-function as a string 


aim Valuation FunctionID 


signed short 


0..32767 


identifier of the valuation-function (see VFT) 



Fig. 12 



Functions-ldentification-Table: [FIT - table of the basic subfunctions used in the valuation-function] 
a.) for SQL-functions: 

column: datatype value-range meaning: 



Function ID (PK) 


signed byte 


-1..127 


identification-number of the basic function 


Function BitCode 


number(19) 


0..2 64 -1 


bitcode of this basic function (only one bit is set) 


Function Name 


char(5) 


5 Bytes 


function-name 


Function Type 


byte 


0..99 


0 = value, 1 = unitary, 2 = binary, 3 = ternary, ... 


Function Flatten 


signed byte 


-127. .127 


degree of flattening [+ = steepening, - = flattening] 


Function Template 


varchar2(99 


<99 Bytes 


SQL function-template 


Function Description 


varchar2(99 


<99 Bytes 


optional description of the basic sub-function 



Fig. 13a 
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F.ID 


Function BitCode 


F.Name 


F.T 


F.F. 


Function Templats 


Function ^Description 


0 


1 


NUM 


o 


o 




3 constsnt numbBr follows 


1 


2 


ENGY 


0 


o 


ELT .energy after 


energy after execution — 


2 


4 


GRAD 


o 


o 


ELT .energy aftGf 
—ELT .energy before 


energy gra ten 


3 


8 


VALUE 


0 


0 


CLT(n). <columnl\lr> 


vsluG in ths following 
column-number (last row) 


4 


16 


EREG 


0 


0 


< EnergyRegister ID> 


ID of the energy-register 


5 


32 


SGN 


1 


0 


SIGN( %s ) 


algebraic sign 


6 


64 


ROUND 


1 


0 


ROUND( %s, 0 ) 


rounded 


7 


128 


INT 


1 


0 


FLOOR* %s ) 


truncated after dec. point 


8 


256 


ABS 


1 


0 


ABS( %s ) 


amount 


9 


512 


NEG 


1 


0 


-( %s ) 


negation 


10 


1.024 


ADD 


2 


1 


( <%s) + (%s) ) 


addition 


1 1 


2.048 


SUB 


2 


-1 


( (%s) - (%s) ) 


subtraction 


12 


4.096 


MUL 


2 


4 


( (%s) * (%s) ) 


multiplication 


13 


8.192 


DIV 


2 


-4 


( (%s) / (%s) ) 


division 


14 


16.384 


MOD 


2 


-2 


MOD( %s, %s ) 


rest of division 


15 


32.767 


SQRT 


1 


-8 


SQRT( %s ) 


square- root 


16 


$1.0000 


CBRT 


1 


-12 


POWER( %s, 1/3 ) 


cube-root 


17 


$2.0000 


MIN 


2 


-10 


LEAST( %s, %s ) 


minimum 


18 


$4.0000 


MAX 


2 


-10 


GREATEST! %s, %s ) 




19 


$8.0000 


LN 


1 


-48 


Ll\l( %s ) 


natural logarithm 


20 


$10.0000 


EXP 


1 


48 


EXP( %s ) 




21 


$20.0000 


LD 


1 


-32 


LOG( 2, %s ) 


log^rith^on"^ 


22 


$40.0000 


POT2 


1 


32 


POWER( 2, %s ) 


2nd power of ... 


23 


$80.0000 


SIN 


1 


-64 


SIIM( %s ) 




24 


$100.0000 


COS 


1 


-64 


COS( %s ) 


cosine 


25 


$200.0000 


TAN 


1 


127 


TAN( %s ) 


tangent 


26 


$400.0000 


AS IN 


1 


127 


ASIN( %s ) 


arc sine 


27 


$800.0000 


ACOS 


1 


127 


ACOS( %s ) 


arc cosine 


28 


$1000.0000 


ATAN 


1 


-127 


ATAN( %s ) 


arc tangent 


29 


$2000.0000 


SINH 


1 


40 


SINH( %s ) 


sine hyperbolic 


30 


$4000.0000 


COSH 


1 


50 


COSH( %s ) 


cosine hyperbolic 


31 


$8000.0000 


TANH 


1 


-127 


TAI\IH( %s ) 


tangent hyperbolic 


32 


$1.0000.0000 


LOG 


2 


-64 


LOG( %s, %s ) 




33 


$2.0000.0000 


POT 


2 


64 


POWER( %s, %s ) 


n-th power of ... 


34 


$4.0000.0000 


OR 


2 


1 


I I /Ob/ | V /OS/ } 


bitwise OR 


35 


$8.0000.0000 


AND 


2 


-1 


( (%s) & (%s) ) 


bitwise AND 


36 


$10.0000.0000 




2 




UCUUUl\ /OS, /OS, I, U J 




37 


$20.0000.0000 


LE 


2 


-127 


DECODEf GREATEST %s - %s. 


less-equal 


38 


$40.0000.0000 


GE 


2 


-127 


DEC0DE( LEASTt %s -%s, 0 ), 0, 


greater-equal 


39 


$80.0000.0000 


FRAME 


1 


-10 


HRFATF^Tf I FA^Tf %c -1-197 \ 
UnCMlLOlv LCMo I v /OS, + | f r 

-128 ) 


frame to signed-byte: 
max. = 127, min. = -128 


40 


$100.0000.0000 




1 


-64 


M Si OLc\ j.O S. ±(/l o. 
\ 1 C5f /Ois) +U fi /oSJ/Z +1^4-61 

%s)/4 +(8 & %s)/8 + .... 


number of bits in the 
integer value 


41 


$200.0000.0000 


S__REG 


0 


0 


ADT. all source Registers- 
BitCode 


bitcode of the source- 
register 


42 


$400.0000.0000 


D REG 


0 


0 


ADT. all dest Registers BitCode 


bitcode of dest. -register 


43 


$800.0000.0000 


AIM__F 


0 


0 


VAL( fKDl.aimJulfil!ed_Flag- 
Function ) 


result of the boolean 
aim-fulfilled-f unction 

















Fig. 13b 
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b.J for machine-code functions: 

column: datatype value-range meaning: 



Function ID (PK) 


signed byte 


-1 ..127 


identification-number of the basic function 


Function BitCode 


number(19) 


0..2 64 -1 


bitcode of this sub-function 


Operations BitCode 


number 


0..2 128 -1 


bitcode of the used opcodes in this function 


Registers BitCode 


number 


0..2 128 -1 


bitcode of the used registers in this function 


Function Name 


char(5) 


5 Bytes 


short notation of this sub-function 


Function Type 


byte 


0..99 


0 = value, 1 = unitary, 2 = binary, 3 = ternary, ... 


Function Flatten 


signed byte 


-128.. 127 


degree of function-flattening (1 £ f(x) = x) 


Function OpCodes 


number 


1..2 128 -1 


sub-function in machine-code 


Function Description 


varchar2(99 


<99 Bytes 


optional description of the sub-function 



Fig. 14a 



Func.lD 


Func. BitCode 


Oper. BitCode 


Beg. BitCodt 


Func Name 




— — 

Func. OpCodes 


Function Descript. 


0 


1 


$A000.4008 


< energy > 


FRAME 


1 


s.b. Fund 


prevent overflow 


1 


2 


: 28800.0009 


< energy > 


SGN 


1 


s.b. Func. 2 


signum 


2 


4 


$0000.0002 


< energy > 


IMEG 


1 


<NEG> 


negation 


3 


8 


$0000.0200 


< energy > 


MUL2 


1 


<SHLI> 


division by 2 


4 


16 


$0000.0400 


< energy > 


DIV2 


1 


<SHRI> 


multiplication by 2 


5 


32 


$0000.0100: 
4A00.8018 


<D0>|<en> 


ILOG2 


1 


s.b. Func. 3 


mogarithm dualis 


6 


64 


S1000.C000: 
0000.0000 


(FP0)|<en) 


ISQRT 


1 


s.b. Func. 4 


square-root 


7 


128 




s. 1.4.2 


ICBRT 


1 


s. above 1 .4.2 


cube-root 


8 


256 


$0000.8000 


<en-1)|(en) 


MOV 


2 


<M0V> 


copying of one reg. 
before energy-reg. 


9 


512 


$0000.8000 


(en-1)|(en> 


SWAP 


2 


s.b. Func. 5 


swap with reg. 
before energy-reg. 


10 


1024 


$0001.0000 


<en-1>[<en> 


ADD 


2 


<ADD> 


addition with -"- 


1 1 


2048 


$0002.0000 


(en-1>|<en> 


SUB 


2 


<SUB> 


subtraction of -"- 


12 


4096 


$0004.0000 


(en-1)|{en} 


MUL 


2 


<MUL> 


multiplied with -"- 


13 


8192 


$0008.0000 


<en-1>|<en> 


DIV 


2 


<DIV> 


division by 
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Function: 


OpCodes of: (machine-code compilation of these mnemonics, here a Motorola-Example) 


Func. 1 


CMPI127,<E>; JLE < + 2) ; MOVI #1 27,<E) ; CMPI - 1 28,(E> ; JGE ( + 2) ; MOVI #-1 28,(E' 


Func. 2 


TST(E); JGE(+3); M0VI#-1,{E); JMP< + 5); JGT ( + 3) ; MOVI #0,(E) ; JMP < + 2> ; 
MOVI # + 1,(E) 


Func. 3 


MOVI #31, DO; BTST D0,<E> ; JEQ (+3) ; DJMP D0,<-2) ; ADDI#1,DO; MOVE D0,{E) 


Func. 4 


FILD <E> ; FSQRT ; FIST <E> 


Func. 5 


MOVE <E-1),-(A7) ; MOVE <E),(E-1 ) ; MOVE (A7) + ,(E) 



Fig. 14c 
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Valuation-Function-Table: [VFT - Table of the valuation-functions] 

column: datatype value-range meaning: 



Valuation Function ID (PK, 


signed short 


±32767 


identifier of the valuation-function (energyspecif. neg.) 


ValuationFunctionType 


chard) 


'E'l'A' 


'E' = energy-valuation, 'A' = valuation for reaching 
closeness to programming-aim, ... (maybe further) 


Valuation Function Mode 


boolean 


op 


0 = SQL-mode; 1 = machine-code mode 


Valuation Function 


varchar2(99 


<99 Bytes 


valuation-function for energy- or aim-attainment 


execution counter 


integer 


0-2 32 -1 


number of uses of this valuation-function 


used Functions BitCode 


number(19) 


0..2 64 -1 


BitCodes of all subfunctions 


Function iD Chain 


varchar2(99 


<99 Bytes 


chain of subfunctions (one byte = one Function ID) 


avg Func execution time 


integer 


0-2 32 -1 


average by val. -func. -execution needed clock-cycles 


boundary value counter 


integer 


0-2 32 -1 


counter incremented if the result is -1 28 or + 1 27 


low value counter 


integer 


0-232-1 


counter incremented if the result inside + 1 6 


ValuationFunctionvalue 


signed byte 


-128.. 127 


valuability of the valuation-function = SAC. Self- 
Valuation Aim/Energy( Valuation Function, Values ) 



ID 


Ty 


M 


Valuation Function 


-1 


'E' 


0 


MAX[ MINf SGN( EnergyReg '-EnergyReg 0 ) ■ SQRT( EnergyReg '-EnergyReg 0 ) 
-32- T[ CLT(i). Register changed BitCode &( i 2 A Energy Register ID ) } , +127], -128] 


0 


'A' 


0 


MAX[ MIN[ 16-71 CLT(i). Register - changed ' BitCode & .all dest Register BitCode } 
+ 16-JI CLT(i) .Register source BitCode & ADT .all ' source Register BitCode } 
+ 32- ADT .aim fulfilled ' Flag _Function( AimJD ) -CLT(i). Processor Mode changed 
-Vi-CYMS] .cycles of execution -( CLT '{\).active\ inactive ChkSum corrupt ) 
-( CLT(i). Exception _vect changed >Q ) -{ CLT{\).Number_of_Exception>0 ) 
- 1 / 2 ( CLT(i). OpCode length or jump > 4 or < 0 ), +127], -128] 


ex# 


used F. BitCode 


Function ID chain 


ex.T 


bdy# 


low# 


F.Val 


0 


$ 189. 0040. 983B 


2,5; 2,15; 12; 4,22,3,1 1 ,35,40,1 ,32,12; 1 1 ; 39 


0 


0 


0 


0 


0 


SEE9.0001.3AAA 


3, 1 1 ,42,35, 1 , 1 6, 1 2; 3, 1 2,41 ,35, 1 , 1 6, 1 2, 1 0; 
43,1,32,10, 3,7,11; 3,16,1,5,13,11; 3,3,11; 3,5,11 
3,5,5, 1 0; 3,8,5, 1 0; 3,9, 1 ,0,37, 1 1 ;3,9, 1 ,5,38, 1 1 ;39 


0 


0 


0 


0 
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Status of the Artificial Consciousness: [SAC - status-values of the AC-program (only 7 row)] 
column: datatype value-range meaning: 



Programm StartDate 


timestamp 


datime 


date and time of the start of the AC-program 


actual Processor Mode 


integer 


0-2 32 -1 


flags above CCR | control-register-bits 


actual CPT index 


byte 


1..255 


CBT( max(i) = actual CPT Nr ) = actual CPT 


CxT counter 


short 


1 ..65535 


number of creatings of the dynamic CxT-tables 


Aims total 


short 


1.. 65535 


number of total programming-aims 


Aims soluted 


short 


0.. 65535 


number of solved programming-aims 


actual Aim ID 


short 


0.. 65535 


ID of the actual programming-aim 


AimValuation Mode 


boolean 


0|1 


mode of the programming-aim-specific valuation- 
function: 0 = SQL-mode; 1 = machine-code mode 


AimValuation FunctionID 


signed short 


0.. 32767 


actual VFT. Valuation Function ID referring the 
closeness to the programming-aim 


AimSelfValuationFunc 


varchar2 
(400) 


max. 400 
Chars. 


PL/SQL-valuation-function referring the efficiency of 
the valuation-function 


EnergyValuationMode 


boolean 


0|1 


mode of the energyspecific valuation-function 
0 = SQL-mode; 1 = machine-code mode 


Energy Valuation Func ID 


signed short 


-1.. -32768 


actual VFT. Valuation Function ID for energy-valuation 


EnergySelfValuationFunc 


varchar2 
(400) 


max. 400 
Chars. 


PL/SQL-valuation-function referring the efficiency of 
the energyspecific valuation-function 


max Valuation Function 


signed short 


0.. 32767 


highest ID of all valuation-functions in the VFT. 


min Valuation Function 


signed short 


-1 ..-32768 


lowest ID of all valuation-functions in the VFT. 



Fig. 76 
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Energy-Learn-Table: [EL T - appraises energyspecific actions in dependence of the used initial-conditions] 
column: datatype value-range meaning: 



Energyaction (PK) 


number 


0..2 128 -1 


max. 1 6 byte opcode-combination of the action 
which changed the energy-register. 


IniConNr (PK) 


signed byte 


-31. .30 


number of the used initial condition 


Energy before 


integer 


0..2 32 -1 


energy-register before execution 


Energy after 


integer 


0..2 32 -1 


energy-register after execution 


min Operations BitCode 


number 


0..2 128 -1 


bitcode of the probably used opcodes. 


max Operations BitCode 


number 


0,.2 12 8-1 


bitcode of the possibly used opcodes. 


Register changed BitCode 


number 


1..2 128 -1 


bitcode of the by action changed registers. 


Register source BitCode 


number 


1..2 128 -1 


bitcode of the probable source-registers. 


used cycles of execution 


short 


1.. 65535 


needed clock cycles for the energyspecific action 


Energy valuation 


signed byte 


-128.. 127 


result of the actual VFT.Energy valuation Function 


Valuation Function ID 


signed short 


-1.. -32768 


used energyspecific valuation-function 
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Energy-Base-Table: [EBT - evaluation of the energyspecific actions] 
column: datatype value-range meaning: 



EnGrcjy 3ction (PK) 


number 


Q 2 128 -1 


max. 1 6 byte opcode-combination of the action 
which changed the energy-register. 


Execution counter 


"byte 


Q 255 — 


number of the ELT-entnes until now. 


FatalErrorcounter 


byte 


0..255 


number of the occurred fatal errors: 

fatal errors correlate the columns 3-7 of the above 

learn-table, except Divide-Error or Overflow-Exc. 


low Error counter 


byte 


0..255 


number of Divide-Errors or Overflow -Exceptions 


avg Energy after 


integer 


0..2 32 -1 


average energy-value after the action 


allRegdestBitCode 


number 


0..2 128 -1 


S ELT. Register changed Bitcode V ELT(OpCode) 


cutRegdestBitCode 


number 


0..2 128 -1 


ELT. Register changed Bitcode V ELT(OpCode) 


a 1 IRegsourceBitCode 


number 


0..2l 28 -1 


3EU. Register source Bitcode V ELT(OpCode) 


cutRegsourceBitCode 


number 


0..2 128 -1 


CELT. Register source Bitcode V ELT(OpCode) 


maxOperation BitCode 


number 


0..2 128 -1 


^ELT.max Operation BitCode V ELT(OpCode) 


mi n_0 perationBitCode 


number 


0..2 128 -1 


CELT. min Operation BitCode V ELT(OpCode) 


allOperationBitCode 


number 


0..2 128 -1 


ii ELT.min Operation BitCode V ELT(OpCode) 


cutOperationBitCode 


number 


0..2 128 -1 


£ ELT. max Operation BitCode V ELT(OpCode) 


max write value 


integer 


0..2 32 -1 


maximum of all energy-values after energy-action 


min write value 


integer 


0..2 32 -1 


minimum of all energy-values after energy-action 


avg write value 


integer 


0.. 232-1 


average of all energy-values after energy-action 


max write gradient 


integer 


0..2 32 -1 


maximum gradient of the changes energy-register 


min write gradient 


integer 


0..2 32 -1 


minimum gradient of the changes energy-register ## 


avg write gradient 


integer 


0..2 32 -1 


average gradient of the changes energy-register 


equal value probability 


signed byte 


-128. .127 


probability of equal result of energyspecific action 


avg Energy gradient 


signed int 


±2 31 


average value-gradient of this energyspecific action 


equal Gradient probability 


signed byte 


-128.. 127 


probability: gradient is constant 


avg cycles of execution 


short 


1.. 65535 


average needed clock cycles for this action 


avg Energy valuation 


signed byte 


-128. .127 


result of the actual VFT.Energy valuation Function 


ValuationFunctionJD 


signed short 


-1.. -32768 


ID of the used energy-valuation-function 



Fig. 18 
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3.2 Flowchart of the AC-Program: 

3.2. 1 CxT(i) value assignments: 

ORT & CRT(i) value assingments: 

ORT.Register ID dest := log 2 ( g/f(OLT.Register_changed Mask), of the regarded changing ) 

ORT.Register ID source := Register ID( C° ), if ORT.calculation code > 0, otherwise -1 

ORT.value before change : = value(Register_ID_dest), before opcode-execution 

ORT.value after change := value(Register ID dest), after opcode-execution 

ORT.gradient if signed := MAX[ MIN[ ORT.value, after change - ORT.value beforechange, +127], -128] 
ORT.gradient if unsigned := MAX[ MIN[ ORT.value after change - ORT. value before change, +127], -128] 
ORT.Operation BitCode 1 ■(Flags'*Flags°)&&V(V'=V°)&&[ NF&&(V,° <0) | | ZF&&(V!°=0) ] 

+ 2-[(V l ' = -V l °)&&V"'(V = V 0 )] + 4-[(V l '=~V l °)&&V~(V' = V°)] + 8-[(V,' = 0LB)&&V~(V' = V°)] 

+ 164(V l '=V l o + 0LB)&WlV'=V o )] + 32-[(V l '=V l o -0LB)MV-(V'=V o )] + 64.[(V l , =V ! o -0LB)&&VlV'=V°)3 

+ 1284(V l '=V l °/0LB)&&VTtf , = n] + 256-[(V l '=V l °%0LB)&^^ 

+ 2 10 4(V I , = V I °/2 A OLB)&&V1V'=V°)] + 2 1 M(V I I =^ 

+ 2 13 -(Flags^Flags°)&&V(V'=V o )&&[(ZF=1)&&(2'0LB|~V°)| |(ZF=0)&&!(2'0LB | V, 0 ) ] 

+ 2 1 4 - (Flags VFIags 0 )&&V(V = V°)&&[ NF&&(V, ° < OLB) | | ZF&&(V, ° = OLB)] + 2 1 5 - [( V, ' = C, ° )&&V"(V = V°)] 

+ 2 16 -[(V I , =V I 0 +C| 0 )&&V7V , = V 0 )] + 2 17 4(V I , =V I 0 -C I 0 )&&V1V' = V 0 )] + 2 18 4(V 1 '=V I 0 -C| 0 )&&V1V' = V°^ 

+ 2 19 -[(V I '=V I °/C I °)&&V1V , =V°)] + 2 20 .[(V I , =V^ 

+ 2 22 -[(V l , =V l 0 /2 co )&&V1V=V 0 )] + 2 23 -[(V l , =V l 0 |C l °)&&V-(V = V 0 )] + 2 24 .[(V l ' = V l 0 &Ci 0 )&&V-(V , = V°)] 
+ 2 25 -(Flags , ^FIags°)&&V(V , =V 0 )&&[(ZF=1)&&(2^C l 0 |~V,°) | |(ZF=0)&&!(2X I ° | V,°) ] 
+ 2 26 -(Flags'*Flags 0 )&&V(V'=V°)&&[ NFS&(V,° <C,°)| |ZF&&(V,° =C,°) ] 
+ 2 27 -[(IP' < IP°) | | (IP' >IP°+4)]&&(Flags' = Flags 0 )&&V(V'=V°) 

+ 2 28 -[(IP' < IP°)| | (IP 1 >IP°+4)]&&(Flags' = Flags 0 )&&V(V=V°)&&(NF&!VF|!NF&VF) + ...VJcctCCR) 
+ 2 4 °-{[(IP' < IP°) | | (IP' > IP° + 4)]&&(V,' = V|°-1)| | (V,' =-1 )}&&(Flags' = Flags °)&&V(V'=V°) 
+ 2 41 -[( IP' = IP°±OLB)&&((SP) = IP° )&&(Flags' = Flags 0 )&&V~{V=V°) 

+ 2 42 -[( IP' = -4(SP) )&&(Flags' = Flags°)&&V(V'=V 0 ) + 2 43 -[(V l l ^V l °)&&(! other lnteger Operation BitCode)] 

+ 2 44 - [( V F VV F ° )&&( ! other_FloatingPoint_Operation_BitCode)] + 2 45 ■ [(CCR-Flags' = 0) & & V( V F ' = 0)] ■ 

+ 2 46 -[(V,' = C F 0 )&&V-(V'=V 0 )] + 2 47 -E(V F '=C i °)&&VlV , = V°)] + 2 48 -[(V F ' = V F ° + C|°)&&V~(V = V°)] 

+ 2 49 4(V F '=V F o -C l o )&WlV , =V o )] + 2 50 4(V F ' = V F o -C| O )&&VlV'=V o )] + 2 51 -[(V F ' = V F o /C| O )&&VlV , = V°)] 

+ 2 52 -(Flags'*Flags°)&&V(V'=V 0 )&&[ NF&&(V F ° < C,°) | |ZF&&(V F ° =0,°)] 

+ 2 53 -[ (V F ' = 1.0)| |(V F ' = 0.O)| |(V F '=7i)j |(V F '=e) ]&&V(V'=V°) 

+ 2 54 .[(V F '=-V F °)&&(V F ° <0)&&V-(V' = V o )] + 2 55 -[(V F ' = C F o )&&V-(V'=V°)] 

+ 256.[(v F ' = V F 0 +C F 0 )&&V-(V'=V D )] + 2 57 -[(V F ' = V F 0 -C F 0 )&&V(V' = V 0 )] 

+ 2 58 4(V F '=V F °.C F °)&W1V'=V°)] + 2 59 4(V F '=V F VV^ 

+ 2 61 4V F ' = sin(V F 0 )]&&VlV'=V 0 ) + 2 62 -[V F '=cos(V F °)]&&V"(V'=V 0 ) + 2 63 -[(V F '=atan(V F 0 ))&&V"(V'=V°)] 

+ 2 64 -[(V F ' = V F °.2 A V F _i °)&&V-(V'=V°)] + 2 65 -[(V F ' = v F -i •log 2 (V F °)&&V-(V'=V 0 )] 

+ 2 66 -( Flags VFIags°)&&V(V' = V°)&&t NF&&(V F ° < C F °) | | ZF&&(V F ° =C F 0 )] + 2 67 -[(V!' = C $ °)&&V"(V' = V 0 )] 

+ 2 68 -[(V s '=C|°)&&V"(V'=\/ 0 )] + ... , where V" =value_after_change (-> Flags), V° =value_before_change 

C° =value(Register_ID_source). Here has to be checked over all RegisterJDsource(eq.kind). 

Though equal Register-ID's in the PK several bits can be set. [p.e. because 

4 = 2 + 2 = 2*2 = SHL(2) = ...] 

Fig. 19 

OLT & CL T(i) value assingments: 

OLT.Processor Mode Changed := IX EF!ags^/SR w & ! S'2 A CCR_Flags } > 0 | | 

ORT.value after_change( Register _ID of a special-register ) 

OLT.aim valuation := VFT.Aim_Valuation_Function( SAC.Aim Valuation FunctionID, ORT.xxxxx, 
Registers changed BitCode, Registers source BitCode, minOperationsBitCode, 
max Operations BitCode, used cycles ofexecution, ... ) 

CLT(n).gradient aim valuation := CLT(n).aim valuation - CLT(n-1).aim valuation 

all other column-assignments are declared adequate in the OLT-description in fig.6. 

Fig.20 
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OBT & CBT(i) value-assingments: 

OBT. Execution counter := Execution counter + 1 

OBT.FatalError counter : = FatalError counter + ( 0 < OLT.NumberofException DivideError, 

Overflow ) | | OLT.activeChkSumcorrupt | | OLT.inactiveChkSumcorrupt | | 

OLT. Exception vect changed j | OLT. Processor Mode changed ) 

OBT. Jump JongOpprobability := MAX[ MIN[ Jumpprobability + (OLT.OpCodelengthorJump < 0 ) 

+ (OLT.OpCode length or jump > 4), +1 27], -1 28] 

OBT. avg OpCodeJump length : = (execution_counter*avg_OpCodeJumplength 

-t-akt.OpCodeJump length) / (execution_counter + 1) 

OBT.OpCode len unconfirmed : = OpCodelenunconfirmed | | ( avg OpCode length ^ 

act.OpCode length ) 

OBT.avg cycles of execution : = ( execution counter * avgcyclesofexecution + 

act.cycles of execution ) / (execution counter+ 1) 

OBT.execcyclesunconfirmed : = execcyclesunconf irmed | j (avg cycles of execution ^ 

act.cycles of execution ) 

OBT.Registerwriteprobability : = MAX[ MIN[ Registerwriteprobability +2*[ ( min.Reg.ID < 

ORT.ColumnJDOLT < max. Reg. ID )&& ORT.valuebeforechange * ORT.valueafterchange ] - 

1, -127], -128] 

OBT.Register copy probability := MAX[ MIN[ MIN( Register copy probability +2*[ ( min.Reg.ID < 

ORT.ColumnJD OLT < max. Reg. ID )&& ORT.value before change ^ ORT.value after change 

&&( min.Reg.ID < ORT.ColumnJD source < max. Reg. ID ) ] -1 , +1 27], -1 28] 

OBT.Memory write probability :- MAX[ MIN[ Memory write probability +2*[ ( min.Adr.Reg.ID < 

ORT.ColumnJD OLT < max.Adr.Reg.ID )&& ORT.value before change ^ 

ORT.value after change ] -1 , +1 27], -1 28] 

OBT.Memory_copy_probability := MAX[ MIN[ Memory_copy_probability +2*[ ( min.Adr.Reg.ID < 
ORT.ColumnJD OLT < max.Adr.Reg.ID )&& ORT.value before change ^ 

ORT.value after change &&( min.Adr.Reg.ID < ORT.Column ID source < max.Adr.Reg.ID ) ] -1, 

+ 127], -128] 

OBT. Reg to Mem probability := MAX[ MIN[ Reg to Mem probability +2*[ ( min.Adr.Reg.ID < 

ORT.ColumnJD OLT < max.Adr.Reg.ID )&& ORT.value before change ^ ORT.value after- 

change &&( min.Reg.ID < ORT. Column I D source < max.Reg.ID ) ] -1, +127], -128] 

OBT.Mem to Reg probability := MAX[ MIN[ Mem to Reg probability +2*[ ( min.Reg.ID < 

ORT.ColumnJD OLT < max. Reg. ID )&& ORT.value before change ^ ORT.value after change 

&&( min.Adr. Reg. ID < ORT.Column ID source < max.Adr.Reg.ID ) ] -1, +127], -128] 

OBT.Multi Reg write prob : = like in Register write probability , but with min.2 appropriate 

ORT.Column ID OLT -entries. 

OBT.Muiti Mem write prob : = like in Memory write probability , but with min.2 appropriate 

ORT.ColumnJD OLT -entries. 

OBT.Multi Reg to Mem prob : = like in Reg to Mem probability , but with min.2 appropriate 

ORT.Column ID OLT + Column ID source -entries. 

OBT.Multi_MemJo_Reg_prob : = like in Mem_to_Reg_probability , but with min.2 appropriate 

ORT.Column ID OLT + Column ID source -entries. 

OBT.xxx Reg source | dest BitCode: see table-description 

OBT.xxx calculation BitCode: see table-description 

OBT. max write value : = MAX( max write value, ORT. value after change ) 

OBT.min write value : = MIN( min write value, ORT.value after change ) 

OBT.avg_write_value : = ( execution counter * avg write value + ORT.value after change ) / 

(execution counter + 1 ) 

OBT.max write gradient := MAX( max write gradient, ORT.value after change - 

ORT.value before change ) 

OBT.min write gradient := MIN( min write gradient, ORT.value after change - 

ORT.value before change ) 

OBT.avg write gradient : = ( execution counter * avg write gradient + ORT.value after change - 

ORT.value before change ) / (execution counter+1) 

OBT.evaluated source [Num]Register : = probability-function( xxx Reg source BitCode, 

confirmation counter ) 
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OBT.evaluated dest Register[2] : = probabifity-functionj xxxRegdest BitCode, confirmation-counter ) 

OBT.evaluated Operation ID := probability-functionj xxx Operation BitCode, confirmation-counter) 

OBT.Confirmationcounter := Confirmation_counter + existi equivalent OLT + ORT-eintry with lower 

IniConNr ) . 

OBT.max aim valuation : - MAX( max aim valuation, OLT.aimvaluation ) 

OBT.avg aim valuation : = ( executioncounter * avgaimvaluation + OLT.aim valuation ) / 

(execution counter-l- 1) 

CBT(n).max_grad_aim_valuation := MAX( CBT(n)max_aim_valuation, CLT(n).aim_valuation ) 

- CBT(n-1).max aim valuation. 

CBT(n).avg_grad_aim_valuation := ( execution_counter * CBT(n).avg_aim_valuation 

+ CLT(n).aim valuation ) / (execution counter+1) - CBT(n-1).avg gradaim valuation 

Fig. 21 



3. 2.2 ELT and EB T value-assignments: 

ELT.max Operations BitCode := OLT.max Operations OpCode 

ELT.min Operations BitCode := QLT.min Operations OpCode 

ELT.Register changed BitCode : = OLT. Registers changed BitCode 

ELT.Register source BitCode : = OLT.Registers source BitCode 

ELT.Energy_Valuation := VFT.Energy_valuation_Function( SAC.Energy Valuation FunctionID, 

Energyafter, Energybefore, RegisterschangedBitCode, RegisterssourceBitCode, 

min Operations BitCode, max Operations BitCode, used cycles of execution, ... ) 

ELT.Valuation Function ID := for calculation of Energy Valuation used VFT. Valuation Function~iD~ 
EBT.avg Energy after : = ( execution counter ■ avg Energy after + ELT.Energyafter ) / 

(execution counter + 1 ) 

EBT.equal _ value probability := equal value probability + 2 ( avg Energy after = ELT.Energy after ) -1 
EBT.avg Energy gradient : = ( execution counter ■ avg Energy gradient + ELT.Energy after - 

ELT.Energy before ) / (execution_counter+ 1) 

EBT.equal gradient probability := equal gradient probability + 2-( avg Energy gradient = 

ELT.Energy after-ELT.Energy before ) -1 

EBT.xxx Operations [Registers BitCode see table-description 

EBT.avg_cycles_of_execution : = ( execution counter ■ avg cycles of execution + ELT.used cycles- 

of execution ) / (execution counter+ 1) 

EBT.avg Energy Valuation := ( execution counter ■ avg Energy Valuation + ELT.Energy valuation ) 

/ (execution_counter+ 1 ) 

Fig.22 



3.2.3 Definitions needed to read the flowchart: 

I directives | denotes a directive or a short sequence of directives. 
< condition fulfilled ? ) Yes: branches horizontally, No: continue below. 
( continuing-label )"~de notes a label to or from another part of the flowchart. 

|| block of directives \ denotes a block of earlier defined directives. 



In the flowchart because of the complexity not all things are described until the smallest detail, 
but the fundamental functionality is presented clear and comprehensible. 

Self-evident things like closing a database-cursor or cofilling not explicit mentioned but existing 
table-columns (which do not need a special algorithm) are not performed additionally, because the 
meaning of these columns is already declared in 3.1.2 an their assignment-formulas in 3.2.1 or in 
3.2.2. 

In the flowchart means "generate ORT-entry and actualise OBT" what is already shown in the 

value-assignments in fig. 19-21. 

Fig.23 
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3.2.4 AC-flowchart: 

a.) Initial Preparations: 

| save all register-values. I 

I save all origina l exception-vectors. | 

I 

initialise processor by deleting all breakpoints, clear all flags in the control-register and clear 

flags in the high word of the status/flags-register. 

I 

| create AC-database and load (respectively calculate) the initial table-values. 



capture all exception-vectors to own handlers. . J 

I . 

capture exceptions, which load additional data to the supervisor-stack, by a special exception- 

routine which considers the additional data. . 

__ . 

Misuse one exception-vector-routine to switch to the supervisor-mode and trigger this 
exception (processor switches into supervisor-mode and continues on this vector-address 

where the further flow of program is. 

I 

Pop the onto the stack loaded EFIags^/Statusregister^ so, that when it's loaded the 
Traceu/Traprc-flag is set (to be in the single-step-mode then). 

Pop the ElP^/PCy on the stack so, that when it's loaded by the return from supervisor-mode 

instruction, the processor continues on the memory where the test-opcode was located. 

_ 

Prepare initial test-values in ICT, which are loaded into the registers for the opcode-test so, 
that all register-values and destination-values of the address-registers have got different 
values. . 



| Initialise the DWord-opcode generator-counter to -1 = $FFFF.FFFF 



| Initialise the IniConNr-counter to -32. 



Fig. 24a 
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b .) Base-Learning: 



| increment opcode-generator-counter by 1 and set lniConNr = -32 | 

( did opcode become ^0000. 0000 twice .?_>->( goto action-learning (Fig.24c) ) 
I increment IniConNr by 1 1 < I DB-comrn t 



< IniConNr > 30 ?) 

r — — 



Set all register-values and addressregister-destination-values to ICT. Register value(lniConNr), 
write 8 times NOP after test-opcode-address in memory (behind is the capture-routine for 
Tracef/ZTraprc-Flag cleared) and write the generated test-opcode above the test-address. 



Execute return from supervisor-mode: The EFIags^/SR^-testvalue is now loaded from the 
supervisor-stack and single-step is switched on. E\P n IPC u is loaded from the supervisor- 
stack and the in its vector-address located test-opcode is executed. 


Analyse: 


After the test-opcode-execution the effects of its execution are 
analysed and the analysis-result is stored.: 



{ Did a Non-Trace-Exception occur ? )— 



{ Did at all no Exception occur ? >- 



set OLT. Number of Exception, Flags- 
before execution, etc., actualise OBT 



set OLT. Processor Mode changed, . 
actualise OBT. 



inside single-step-routine - analysis of the opcode-execution-effects. 
| compute the CheckSum of the AC-program and the CheckSum if its inactive copy. | 



{ Checksum of the active AC-Prg. changed ? >- 



< CheckSum of the inactive AC-Prg. changed ?J - 
1 



set OLT. active ChkSum corrupt, jump to 
the equivalent position of the inactive code 
and the corrupt code; actualise OBT. 



set inactive ChkSum corrupt-Flag, repaii 
inactive code; actualise OBT. 



< Was an exception-vector overwritten ? )- 
4 



set the exception-vectors again, write the Ni 
of changed one into OLT. Exception Vector- 
changed, generate ORT-entry; actualise OBT 



Compare the UP n IPC u on the stack (pushed through Trace) with the address of the test- 
opcode and set OpCode length or jump to the difference (framed by min.-1 28,max. 1 27) 



( E/PyPCu was not increased by I..4 b ytes ? )-» | actualise jump-specific OBT-columns 

T Z~Z 



If opcode was shorter than DWord, increase generator up to $<byte>FF.FFFF if length 
was byte, on word-length to $<word>.FFFF and on 3-byte-opcode to $<Word-Byte>FF. 

| Compare the trace-bit on the to stack pushed EFIags TC /SR„ with the original test-value. 

{ -Did a register-value id. Flags change 7 )- 
Loop over all register: ]~ 



Generate ORT+OLT-entries and actualise 
OBT. If the "energy"-register-value changed, 
generate ELT-entry and actualise EBT. 



{Did the dest. -value of an adress-reg. changeP)- 
Loop over all adr.-reg.: | 



Generate ORT+OLT-entries and actualise 
OBT. 



Fig.24b 



c.J Double-OpCode-Acting: 
( Begin of Double-OpCode-Acting [after Base-Learning - Fig. 24b] ) 



OBT-Evaluation: with probability-functions evaluated source [Num]Reg[ister] is derived from 
OBT.xxx Reg source BitCode , evaluated _dest_Register[2] derived from xxx Reg dest BitCode and 
evaluated Operadtion ID is derived from xxx Operation BitCode (considering confirmation counter). 



Define the last data-register as "energy"-register and set to an average value- 



Open 1st Cursor over the OBT. 



Fetch next row from the 1st OBT-cursor, 



( Triple-Opcode-Planning (Fig.24cJ )<^{ Fetch 1 empty ( 1st opcode processed) ? > | 

/ Jump JongOp jirobability > 0 or Y [ADT. unused 1 Register BitCodel 'Aim ID) \ I 

\ &(OBT.cut_squrce Jieg J3itCode}OBT.cutjjest Reg BitCode) J > 0 ? / 

< Execution counter / OBT. OpCode Fata/Error counter (opcode 1) < 5 ?) > I 

— — ~- —4,- t 

I Open 2nd Cursor over the OBT. I I 

I I 
| Fetch next row from the 2nd OBT-cursor. I I 



( Fetch2 empty (2nd opcode processed ? ) > 

/ Jump longOp _probability > 0 or Y [ADT. unused Register BitCode(Aim JD) \ 
" \ &(QBT. cut source _Reg^itCode\OBT. cut dest^eg BitCode) ] (OpC. 2) > 0? / 

— ( Execution count er / OBT . OpCode Fata/Error counter (opcode2) < 5 ? ) 

initialise lniCo nNr = -32 
I 



L 



lniConNr+ 



- ( IniConNr > +30 ? ) 



Initialising and execution using the initial conditions of the corresponding 
IniConNr, like duri ng the base-learning, but now for the double-opcode. 
4 



ISame procedure like in the analysis-block of the base-learning (Fig. 24b), but 
analysis-results now stored into CRT(2), CLT(2) and CBT(2). 



decrement "energy "-register by 1. 



(Jsjhe '^energy^register in the middle or high range ? ) - 



Select and execute an EBT. Energy specific action which has a high 
anergy action valuation and a high confirmation counter. 

I ^ - 



Analysis-block like above. 



Fig. 24c 



d.) Triple-OpCode-Planning: 
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( Begin of Triple-Opcode-Planning [after Double-Opcode-Actions] ) 



CBT-Evaluation: with probability-functions evaluated source JNum]Reg[isterJ is derived from CBT(2). 
xxx Reg source BitCode , evaluated _dest_Register[2] derived from xxx Reg dest BitCode and 
evaluated Operadtion ID is derived from xxx Operation BitCode (considering confirmation counter). 



Open 1 st cursor over the CBT(2) 



Fetch next row from the 1st cursor out of CBT(2) 



Open 2nd cursor, but now over the QBT 



Fetch next row from the 2nd cursor out of OBT. 



( Fetch2 empty (rearppcode processed) ? ) 

_ / Jump JongOp probability > 0 or Y [ADT. unused Register BitCode( Aim ID) \ 
\ &(OBT.cut_sourct ? Reg BitCode\OBT.cut_dest_Reg BitCode) ] > 0 ? / 



initialise IniConNr = -32 



x 

( Quad-Opcode-Planning )<-< Fetch 1 empty (1st opcode processed) ? > 

/ Jump JongOp probability > 0 or ^[ADT. unused Register BitCode( Aim ID) \ 
\ &(0CT(2).cut ^source Reg r_BitCode\0BT(2).cut_dest_Reg_BitCode) J > 0 ? / ~ 

{ Execution counter / CBT[2). OjpCodeJ=atalError counter (opcode 1) < 5 ? ) - 



lniConl\ lr+ 



-( IniConNr > +30 ?) 



[Initialising and execution with the initial conditions of the corresponding | 
IniConNr like during the double-opcode-actions, but now for the triple-opcode || 



Same procedure like in the analysis-block of the double-opcode-actions 
(Fig.24c), but analysis-results now stored into CRT(3), CLT(3) and CBT(3) 
I ~ 



I Decrement "energy" -register and same tryings to increase it like during the 

II double-opcode-actions with equivalent valuation-analysis of the action. 



| Procedure for higher combinations analogous, using CxT(n), where n = sum of opcodes. 
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